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/[EMAIL PROTECTED]/
msg03195.html
[7] http://www.mail-archive.com/[EMAIL PROTECTED]/
msg03203.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
