I need a way of being able to do the following:
A web application has a variable called 'setting'.
When a user first connects to the application, setting should have a value of 'default'.
Setting can be changed in any page.
If a user middle-clicks to open a page in a new tab, that page's setting should be a copy of the current page's setting (a copy, not a reference to it).
If a user opens a new tab and types in the web app's URL, then that page's value of setting should be 'default'.
If a user left clicks a link, then the new page should have the same value for setting as the referring page (the same value, not a copy).
Implementation:
I can obviously do this with a nasty url hack (...?setting=foo), but this gets nasty when there are many settings.
Is there any 'per-tab' storage available on browsers.
Theory:
The theoretical underpinning for this behaviour is the concept of a subsession. All subsessions belong to the session. Subsessions have a parent, if their tab was opened by a middle click. If their page loaded by typing a URL in an empty tab, then the subsession has no parent. Settings can be stored in subsessions, and is a setting is not present in a subsession, the parent's value is used instead.
Has anyone got any ideas on how to do this nicely?
Are there any sites which already behave this way?
Thanks,
Chris.
I think this would work for you: http://www.xul.fr/en/html5/sessionstorage.php
I have written a solution to this issue at:
https://github.com/chrisdew/subsession
It is obviously in early development and may contain bugs.
Related
If you go into amend Settings for a custom tab that you have created before, is there anyway to get the existing websiteUrl and contentUrl values in your configuration page?
The microsoftTeams.getContext method doesn't seem to make these Urls available (like it does entityId).
Thanks.
I think you'll need to persist this your side (e.g. in a database), and re-query them from your settings page. This is exactly why the "save" button won't become enabled until you're ready for it (by calling microsoftTeams.settings.setValidityState) - it's for your code to do whatever it needs before allowing the user to actually save any changes.
I am writing a simple web page, which shows some widgets based on user permission. If user has EDIT permission, the page renders EDIT widget else EDIT widget doesn't shows up.
What is the best way to achieve this?
I, first called a service to get logged in user's permission and then set visibility: none or block based on the permission. But, I see that user can "inspect element" on browser and set visibility accordingly. However, on server-side, I am using #PreAuthorize annotation on DAO to control the user actions.
How to control visibility of UI widgets without user being able to make changes, maybe from server side?
Update : I am looking for JSTL equivalent in GWT
AFAIK there is no JSTL equivalent for GWT.
However there are some 3rd party (i.e. ArcIS) libraries that make display/hiding UI elements based on user permissions more convenient.
However no matter whether you do it manually or using a library you should make sure that you properly secure your backend side (as far as I can tell you are doing that by using method level security).
One important thing to remember when dealing with client side permissions/security:
You should never trust input/actions from the client/browser, because you are not in control of it. So you must always do security on the backend
In my opinion, it really does not matter if the user could theoratically inspect the edit button for example using Browser Dev Tools and make it visible, as long as the the edit action on the backend is properly secured. If you are really that concerned you can remove the elements (i.e edit button) from the DOM instead of hiding it, but it won't make it more secure.
I, first called a service to get logged in user's permission and then
set visibility: none or block based on the permission.
Well instead of setting the visibility none or block, assuming you are using JSP, use JSTL tag
<c:if test="${if the user has permission}">Show widget UI code</c:if>
If the page has n widgets for which the user doesn't has permission, why would you load the code for all the n widgets. It's non performant.
write a panel that shows it's contents based on security settings in the client code
add the widgets to be controlled inside the security panel
the panel will now control the appearance of the children based on security in your client code
As has been mentioned before, and has been recognized by you, client security is only visibility control and thus not sufficient to protect the app.
when is a view scope in an Domino XPage application lost by timeout, when the page is not accessed anymore? Is there a timeout? Or are they lost not until the session is closed (because of a logout or of the timeout)?
I know, that there is the server page persistence configuration in the Xsp Properties. But when is the scope lost, if you do nothing in the browser? You don't work in other tabs, so that there are not too much pages. (Is there an event listener for that, that allows me to print this out?)
Thanks in advance
AFAIK a viewScope object cannot live longer than the user's session. In addition it is bound to the current page's rendering for a given user.
This basically means that there are three options to kill a viewScope object:
move on to a different page
ask for a new rendition of the same page (like re-entering the same URL etc,; in fact this is the same as #1)
terminate the session by logging out, closing the browser etc.
You might want to try youself by building some test pages with a computed field bound to a viewScope variable; make sure that the variable is set through a button or the likes. Another option is to implement the Xpages debug toolbar available from openNTF.
A very simple explanation of all 4 scopes can be found here: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/xpages-scoped-variables.htm, but you might be aware of that already.
I have a nasty issue with Wicket and Ajax on VMWare Horizon. What users see is that ajax-links do not work as expected. To be exact: they work, but seem to act on a older version of the page. For example, when I have a counter, it does seems to handle an ajax-update, but the value is never increased. The value is stored in a Model so I figured it has something to do with page serialization.
I went on to do a more simpler experiment: on the Wicket-Exmaples (see: http://www.wicket-library.com/wicket-examples/ajax/on-change-ajax-behavior) there is a input box. If you press enter, the value is submitted to the page. This works fine in one browser tab.
However, if I open two tabs (by copy-pasting the url in a new tab, let's call them A and B). I submit a value in tab A using enter. I refresh the tab B and get the value what is submitted in tab A.
The only way this can happen seems to be that they read each-other's serialized pages.
How can I prevent this behaviour?
ps. I use Wicket version 6.19.0, the wicket examples seems to run 6.x.
ps2. I noticed this behaviour in Chrome.
To prevent this you should make sure that there are no two or more tabs opened on the same page (i.e. with the same page id).
You can use https://github.com/apache/wicket/blob/2f3b357703df3fe5c49580b3c46d4fd231208474/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxNewWindowNotifyingBehavior.java to be notified when this happens. Just do setResponsePage(getPage().getClass()) to start on a fresh instance.
That is because two tabs work in one session.
The tabs are not considered (because they are not known to the server) for deciding which session a request is for.
If you would do the same with two browsers instead of two tabs it would work fine.
We have a requirement where support for different users in different tabs of a browser window. How can we achieve this in Spring 2.5? The application is based on Users, where users will have their own agents and articles. An internal user should be able to login to different user accounts in different tabs at same time and manipulate their data. Any help is much appreciated.
A browser's cookie store does not distinguish between different windows or tabs when deciding what cookies to send. So a cookie based approach won't help.
My suggestion for an alternative would be to have a hidden "userName" parameter that is passed back and forth as a URL query parameter for all requests from a given tab or window. You could finesse the setting of the parameter in browser requests by using some Javascript to add a hidden parameter to each of the HTML forms in the page just loaded. The parameter value would be snarffed from the query string of the current page URL. You'd just need to make sure that all pages included stuff in the header to load the JS and run it when the page load completed.
Generally speaking, no, because all of the tabs within the browser window share the same cookies.
One way to do it would be use multiple domain names all pointing at the same app. Each domain name would have its own set of cookies. You would need to have some way of switching to a new domain name after you open a new tab.
How about, have a set of bookmark toolbar bookmarks, each corresponding to a different domain name. Control-click on the bookmark and it opens in a new tab. You could provide the users links in your navigation to the different domains that they can drag onto their toolbar.
Depending on what browsers your users are using you could get even slicker - in some browsers Javascript window.open() opens a new tab. You could have the JS compute the new domain name before the window.open().