tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject emptySessionPath=
Date Mon, 04 Jun 2007 15:43:08 GMT

I have a portal application and introduced recently emptySessionPath="true" to
have access to the same objects in the session in my servlets and my portlets,
both sitting in the same webapp.

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?

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.

So I agree with Aaron Evans who reported this issue for JetSpeed [6]:

"I don't think this is a jetspeed problem but rather a tomcat/tomcat SSO
issue, but I was just wondering if others have seen this behaviour."

And like his idea how it should work [7].

So actually there are two issues, (1) always using the same session id, (2) not
invalidating all sessions associated with one session id. I wonder if there has
changed anything for the former since that thread [1] since I'm using the most
recent 5.5 release 23. Or if it is solvable at all. But the latter seems to be a
real issue for me. Can you please comment on it?



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

View raw message