tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: emptySessionPath=
Date Mon, 04 Jun 2007 16:22:14 GMT
Joerg Heinicke wrote:
> First observation I made is the repeated use of the same session id despite
> invalidating the corresponding session. I found out that this is by intention
> [1], but it leaves a strange gut feeling. Why is a session id an arbitrary
> string, which is under normal circumstances really hard to guess - if I do not
> need to predict it at all since I know it when having access to the PC (without
> any XSS issue)? I only have to wait until the user logs in the next time to
> hijack his session, don't I?

It's not easier or harder, since it is possible to maintain a session 
for a user if you know the id. The session id, which is set using a 
session cookie, will change when the user closes the browser.

It should be easy to use a valve (or a filter) to perform additional 
checks if you feel you need them in your particular use case.

> But ignoring that one for the moment and blaming the portlet spec [2] I found
> another issue ... From what I observed not all sessions assigned to this session
> id are invalidated. This seems to be true for different portals, I found at
> least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course
> it's possible that the portals are to blame but I wonder if they manage the
> sessions themselves or if they don't only forward it to the application
> container. At least in Liferay the HttpSession for the portal is invalidated,
> but I can access objects in the session of my webapp (portlets + servlets). Here
> the reused session id gets also very critical.

It's your problem: this is not SSO, and the sessions remain fully 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message