This behaviour is a 'feature' at the moment. If you login as a different user again, you'll get a clean session, and you can only log in as the same user if you know the credentials, so it shouldn't really be a security issue.
But it looks like this kind of behaviour is confusing to users, and actually results in more memory consumption than necessary.
Please, file a JIRA issue, as we'll most probably address this to work like you expect - destroy the HttpSessions upon logout.
As for how to do this at the moment - I don't think there's a ready-made way to do that.
Joerg, in EPP 5.1 released in december, this has been fixed (ie: if you login as a different user you won't see the session data of previous user).
For GateIn, you would have to wait for the 3.2 release or build yourself from trunk.
Hi Marko, hi Thomas,
thank you for your quick answers. I looked at the new class SessionInvalidatorInterceptor which you build to fix the bug GTNPORTAL-1257. The class seems to be intended to affect the HttpSession of the application WAR. It does not affect the HttpSession of the GateIn WAR which is invalidated at logout by the LogoutActionListener of the class UIPortal. At login the Session ID may be reused but for the GateIn WAR a new HttpSession will be created. Right?
We use the JBoss portletbridge to build Seam/RichFaces portlets. The class SessionInvalidatorInterceptor would simply remove all attribute of the HttpSession which leaves it in an invalid state for seam. Because you don't destroy the HttpSession and create a new one the SeamListener (and thus the appropriate Seam lifecycle action) will not be called. This implies that our portlets will not work after relogin as a different user.
SessionInvalidatorInterceptor is not triggered at logout event itself. It detects a logout condition when a new request is performed, and it does this for all requests - including those for portal.war, admin.war ... (which you refer to as GateIn WAR).
The portlet bridge issue sounds interesting. Our testsuite didn't detect that, but maybe no test covers the scenario.
It would be great if you could put together a simple test app do demonstrate this ... and file a JIRA
I patched my GateIn 3.1.0 Server integrating your SessionInvalidatorInterceptor. For our portlets it did not work! Therefore I searched for a simple portlet application in the web and found the example Wesley Hales built for his video tutorial episode 6 (http://downloads.jboss.org/portletbridge/episode6.zip). For that application your interceptor worked!
Adding some logging to the SessionInvalidatorInterceptor I noticed that the request in a call to our portlets is a org.jboss.seam.web.IdentityRequestWrapper with getRemoteUser() always returning null. The wrapped request returns the expected remote user. The IdentityRequestWrapper originates from the org.jboss.seam.web.IdentityFilter which follows org.jboss.seam.web.MultipartFilter and org.jboss.seam.web.Ajax4jsfFilter.
In the web.xml we configured the org.jboss.seam.servlet.SeamFilter with an url pattern "/*". If I delete that line the IdentityRequestWrapper does not occur anymore but our portlet using the Richfaces file upload component ceases to work. Is there another way to get the file upload component to work?
At least for some Seam/Richfaces portlets the solution with the SessionInvalidatorInterceptor does work. Seam tolerates to get the HttpSession purged. But the method ServletLifecycle.endSession() will not be called and thus Seam will not released his resources (e.g. stateful session beans) orderly. Instead of being removed the SFSB will reside in the server, after a while being passivated und after timeout being removed. Since after a logout the HttpSession with the seam contexts is not invalidated we have to wait for the HttpSession to time out to let Seam release its resources. Essentially the same situation.
If a portlet application initializes the HttpSession using a HttpSessionListener it may rely on this, breaking if the HttpSession is purged and the expected attributes do not exist. This kind of (correct) application will not work in GateIn.
The same problem still exists on last EPP5.1 with supported patches
Krashan, please open a support ticket where we can follow up on your particular issue.
Solultion for Seam context clearing after the logout can be found here: http://community.jboss.org/message/590648#590648. In short you have to build gatein from trunk, but using the WCI component from the specified revision. See the thread for details.