tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: emptySessionPath=
Date Mon, 04 Jun 2007 16:57:23 GMT

On Jun 4, 2007, at 8:43 AM, Joerg Heinicke wrote:

> Hi,
>
> 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?


IMO the area of cross-context session management is basically not  
specified in the servlet and portlet specs.  It certainly relies on a  
lot of extrapolation to make a usable product.  My conclusions are  
that to make a usable portal possible, while deploying portlet  
applications as web apps, the servlet container has to create a cross  
context session id, and manage individual sessions for each web app  
context that uses this sessionId, and when one session is invalidated  
in this collection, invalidate all sessions for that sessionId.   
AFAICT this is consistent with the servlet spec, although it is  
certainly not specified behavior according to the servlet spec.

In a little more detail:

- sessions are indexed by sessionId and context-root (or other web  
app identifier)
- invalidating one session (for a sessionId + context-root)  
invalidates all other sessions with that sessionId

After a lot of discussion with the jetty devs I got them to implement  
this, but I've never been able to understand the discussions about  
the subject on the tomcat lists so I'm really not sure what the  
expected behavior of tomcat is.

thanks
david jencks

>
> Regards,
> Joerg
>
> [1] http://marc.info/?t=110779284700005&r=1&w=4
> [2] http://marc.info/?l=tomcat-dev&m=112092302521008&w=4
> [3] http://www.ja-sig.org/issues/browse/UP-1590
> [4] http://issues.apache.org/jira/browse/JS2-582
> [5] http://support.liferay.com/browse/LEP-1852
> [6] http://www.mail-archive.com/jetspeed-user@portals.apache.org/ 
> msg03195.html
> [7] http://www.mail-archive.com/jetspeed-user@portals.apache.org/ 
> msg03203.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message