One of the common misconceptions I’ve come across with XPages developers is that sessionScope will contain the information for the current logged on user. It can, but it may not. And discussions with Serdar Basegmez and Russ Maher over the last couple of days have helped me understand things yet further.
Let’s back up here and cover some very important points:
- XPages applications that require authentication, first hit the Domino HTTP server, which prompts for authentication and issues a SessionID cookie to the browser. Any HTTP or XPages interaction with the server from that point onwards uses the SessionID cookie to identify where the request comes from and keep the authenticated session active. But each XPages application uses its own ClassLoader, so all the scopes – requestScope, viewScope, sessionScope and applicationScope – only hold data for the current NSF. sessionScope holds data for the session for the current application only.
- Moreover sessionScope is for the browser session, not the user session.
- When the user logs out, via a Login or Logout Node from the Extension Library or a redirection to a “/?logout” URL. This clears only the authenticated credentials. Log out and don’t close the browser, check your cookies and you’ll see the SessionID cookie is still there.
What the first point means is that logging into an application from two different browsers as the same user means you’re using separate sessionScope maps. You’re not sharing the same sessionScope map for both browser sessions.
Add those last two points together, and if you set sessionScope variables, just do an HTTP logout, don’t close the browser, go back to an application that requires authentication, log in as a different user: the previous sessionScope variables are still available.
There are a couple of options.
You can clear the sessionScope map or invalidate the session – thanks to Russ for the sample code – facesContext.getExternalContext().getSession(false).invalidate(). But factor in point one from above and you’ll realise that these two mean you can only clear the session for XPages in the current NSF. You don’t have access to any other NSF. So if you log back in, you will have removed sessionScope for the application you ran the SSJS / Java code in, but not in any other application the user accessed during that browser session.
Prior to Domino 9.0, you could remove the SessionID cookie via JavaScript. That meant a new SessionID would be generated next time the user tried to access the server, regardless of whether or not they closed the browser. However, with Domino 9.0 the SessionID cookie was set as HTTPOnly (thanks to Serdar for identifying that was the cause), which means it cannot be accessed via JavaScript. It makes it more secure, but it also means that if you’re returning to an application that requires authentication, you have the same SessionID cookie, so the same sessionScope maps for the rest of the server.
What Serdar did notice was that if you log out – regardless of clearing sessionScope by whatever means – and then go to a page in the database that allows Anonymous access, the SessionID cookie is regenerated. That means new sessionScope maps will be used across the server. But that may not be a desirable option for your applications.
It may be possible to clear the session via a custom servlet, but that’s not been investigated.
So how do you get a unique session for the user regardless of where they’re logging on from? The solution is to put a map into applicationScope where the key is the current user’s effective user name. A userScope. Which is what Nathan added in the last couple of days to OpenNTF Domino API. Many developers may have been doing something similar, or re-initialising sessionScope if the current user changes. But this gives an easy scope accessible based on user name. But because it’s added to applicationScope, it’s still per application. It’s not a userScope shared across the whole server. Of course that would be possible… 😉
I just added two more: serverScope which is a Map for the entire server (as long as the plugin is installed for the whole server rather than localized to an NSF) and identityScope which is a user-specific Map that’s persistent across the entire server.
Be cautious about what you put in them. They don’t have timeouts, so they’ll stick around for a while.
Have you heard anything further about this Paul? This is so systemic to how IBM describes the scoped variables that it rather unnerves me that a user can log out, another log in (in the same browser), and get user-dependent information of the first user. IBM’s Notes/Domino App Dev Wiki page on scoped variables in XPages says, “The sessionScope is useful for using you want to store values for the current session only and specific to the current user”, making me think this is unexpected behavior. (source link: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/xpages-scoped-variables.htm)
It seems that the intention is for the sessionScope to be available only to the active session (which reads as user-dependent). I would be curious to know whether anyone has ever attempted to open / opened a PMR on this.
I haven’t heard anything more about that Eric. But when I’m looking at whether something in XPages is a correct implementation or a bug, my starting point is whether it’s IBM-specific functionality or based on an external framework. If the latter, I look at how it works in that external framework. In this case, session scope is a standard JSF a construct. Looking at how session scope works in JSF, I found this question on StackOverflow http://stackoverflow.com/questions/7031885/how-to-choose-the-right-bean-scope. That confirms it’s linked to the HTTP session, and links to this question http://stackoverflow.com/questions/3106452/how-do-servlets-work-instantiation-session-variables-and-multithreading/3106909#3106909. That confirms it’s linked to the sessionID cookie and it requires session timeout or the browser to be closed. Based on that, I think the App Dev Wiki article is wrong and actually needs to be updated. I suspect a JSF developer coming to XPages would not see anything incorrect in the implementation, but it would be interesting to confirm.
That’s a fair point. I guess I just assumed that it was unique to the XPages implementation. I still think it’s not right, but if it’s JSF’s doing, then I guess IBM’s off the hook. After realizing this was a potential occurrence for a couple applications, I started implementing a destruction of session beans on user navigation away from the application or log out event.
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html
“A session usually corresponds to one user…”
True, but in those implementations, I would suspect the authentication for the session is handled by the JavaEE application. In Domino it’s not handled by the XPages runtime, but by the standard HTTP task. I think Serdar Basegmez identified that accessing an anonymous page after logout does clear the sessionID cookie, because it then starts a new session. Whether the SessionID cookie should be cleared by the HTTP logout is maybe a relevant discussion, but a PMR for that would probably be under HTTP logout rather than XPages functionality. The challenge then would be that it’s not an issue for standard Domino web applications like iNotes. It may be worth raising in Technoasis at ConnectED. Maybe we can get together, I have a demo application that can show the issues.
Oh I get that. I just thought there was management a level up in the XPages runtime, which there isn’t . I just wish the HTTPSession was killed on log out. Oh well, it can’t all be easy, can it?