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 independent.
Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
