I have the impression you fixed the jvmRoute in the new Session(-Id) in ManagerBase, but not in DeltaManager? Even when the context is distributable one might prefer to stick the session to the node where it now originates.
You mean the commented out code ? It would need to be cut & pasted to the delta manager. I had it originally in both managers.
Furthermore: I did not really understand the use case of emptySessionPath,
The use case is when something abuses cross context, such as a portlet container.
but want to indicate 2 problematic areas:
1) If the cookie contains an expired session(-id) then you would allow a new session to be started with the old id. That is not a naive security problem, because the session is empty, so authentication has to be done again etc.
It is still tied to the same user, and as you said the object will be brand new. I don't understand why it is a problem.
But there is a more complex threat: Security of webapps relies on the fact, that session ids are not easily guessable. Once you move into a situation where a user might use the same session id for a very long time (in fact different sessions) the id will loose it's security. Normally it's hard to find out the id of a user session while the session is still active. And the user can at every time end his session. If he is going to use the same Id for many sessions you have a much better chance to get knowledge about the id between sessions and then to just wait for a new session to begin.
That's what I thought at first, but I actually don't think it's a problem.
There was nothing preventing from using a session for a very long time before, depending on the server settings. With the session space (128 bits) we are using, it does not matter, the ids will be unguessable as soon as the random number generator is properly seeded.
And if you really care about security, use SSL ;)
2) There might be problems by putting an arbitrary string coming from an uncontrolled Cookie and using it as a session id inside tomcat. I don't know, if there is a way related to cross site scrpting or injection of malicious code for cookies (of course I know, that there is no scripting inside Cookies, but atackers are very ingenious nowadays). At least one should check the string for formal correctness (e.g. containing only letters and numbers or something similar).
Besides the cross scripting used with a URL, I am not aware of any valid cookie which would cause problems. Invalid cookies will not be parsed.
A global session id list is needed to verify the submitted id exists (across all contexts). I don't think such a list is worth it, though.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
