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.
Related
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.
I'm not sure how to implement this and I'm quite new to Wicket, but the behavior I'm trying to aim for is; when a session timeout occurs, the User is redirected to the login page to relog, when he relogs, he is then redirected to the page he was viewing before.
Any help is appreciated.
The functionality you want only works when the server can identify which page you want to act on. So only stateless form submissions, and bookmarkable URLs will do this. Wicket does this out of the box, but only in the stateless/bookmarkable variations.
Wicket stores the page information (sort of) in the session. When the session has expired this information is no longer available. Then only requests that are not relative to the session/require information that used to be in the session will have the desired effect.
Have you tried the following code in your WebApplication.init() method?
IApplicationSettings asSettings = getApplicationSettings();
asSettings.setPageExpiredErrorPage(PageErrorSessionExpired.class);
Substitute your own WebPage class for my PageErrorSessionExpired here.
I am writing MVC3 web app I need to know at server side when user navigate from one web page to another. I do not need to know from what pages page to which just fact that user navigated. I could find this by adding Session variable to every Home Controller Actions but maybe there is better solution?
Use a global filter attribute for al your controller actions. You can set that attribute in the global asax. In that case you know when an action is hit.
You could try sending AJAX request bound to onbeforeunload browser event.
Basically, it happens on the client side, so the programming should also be in client. Javascript could be the way to go. Though it may deliver some inconvenience to the user.
I was making some test with my JSF-app and when I tried it in the same web-browser on different tabs, in all tabs the last session was present.
How can I prevent this?
That isn't possible without hacking/changing the browser. But this really shouldn't matter. If that causes unintuitive behaviour in your JSF application (e.g. data of one tab is been redisplayed in another tab), then you were apparently storing view scoped data in session scoped beans. You should store view scoped data in view scoped beans instead.
Or if it is purely intended for testing purposes (i.e. you just wanted to test physically separate user sessions), then you should use physically separate browsers. E.g. one Firefox and one Chrome.
Or if you absolutely need to have "one user session per tab/window", then store the logged-in user in a view scoped bean instead of a session scoped bean and exclusively use ajax postbacks to navigate through pages (SPA - Single Page Application).
See also:
How to choose the right bean scope?
How do servlets work? Instantiation, sessions, shared variables and multithreading
How to ajax-refresh dynamic include content by navigation menu? (JSF SPA)
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.