Question

I’m faced with a curious problem in my current project:

I’ve got multiple Spring MVC based web apps deployed on a Glassfish 3.1 server – and I need to be able to “timeout” the user based on the “sesion timeout” parameter in their respective web.xml – no matter in which application the user is on. Please don’t ask why the applications are in separate WARs – the architecture is so. The user is logged in via WebApp A and is redirected to a WebApp B – and then the user can keep jumping to different web apps – I guess you get the idea. The WebAppB etc. have numerous Ajax calls (I’m not even going there) as well. The question, I guess, boils down to the fact that I’m not able to share session data between WebApp A and WebApp B (I may be wrong here – and this is where I require help) and so I don’t have any way to know by checking

httpServletRequest.getSession(false)  

in WebAppB since it returns null in both cases when the first request hits the WebAppB and the first request “after” a session timeout. I have to keep “something” in the WebAppA’s session and check for its existence in WebAppB’s session – which brings me back to the issue of sharing session data within web applications. I cannot use DB storage, since that would mean a DB call on every request. I got a direction by googling that “crossContext” thing in Tomcat helps in such scenarios – but will something like this be helpful in Glassfish ( there’s a “crossContextAllowed” property for sun-web-app.xml which I recently found).

I’ve been stuck with this for quite some time now and I’m not even sure this is a question worth your time – so thanks in advance for trying to help.

Trishul

Answer 1

I cannot help you with the Glassfish implementation, but what you need is a form of Single Sign On between webapps.

To implement this form of SSO you usually need to do two things:

1. Make sure all your webapps share a common root context i.e webapp A is on /commonroot/webappA and webapp B is on /commonroot/webappB. The reason for this is that the same session Id must be delivered to the two webapps when the user switches between them. Session Ids are usually stored in cookies and browsers deliver cookies based on path. There must be a setting on Glassfish (as there is on Tomcat and Jetty) which can “force” webapp A to deliver a cookies on path “/commonroot” (rather than /commonroot/webappA) and webappB to do the same. Any access to webapp A or webapp B will then pull and provide the unique session id from the cookie associated with the /commonRoot path.
2. Once you have all your webapps within the same ‘SSO context’ share a common session for an user, you need to have these webapps access the session from a common, unique store. A DB is a usual way to do it but if you are looking for speed, something like memcached or hazelcast may be more appropriate. The advantage of using a DB is that it additionally provides session persistence: if your session store is bounced, an user making a call with a session which is not expired will be transparently reconnected without having to login again.

Servlet/JavaEE containers usually provide samples of SSO Realms/SessionManagers or equivalent that will directly implement what you require or that you can hack to fine tune to your needs.