Re: session id's really unique?
You run the risk of getting duplicate session id's. However, across contexts you'll have separate Managers, and therefore different sets of sessions. So, you don't run the risk of one context gaining access to another context's sessions. The risk is the one discussed in the other session id thread where if you get duplicate session id's in the same context. Then you've got serious problems. shawn wrote: If I use RequestDispatcher.forward(request, response) to another context am I running the risk of session id conflicts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: session id's really unique?
Just to confirm, If I send use RequestDispatcher.forward(request, response) and send it to another context, that session will be newly managed under the new context (or by the original context) and therefore there is no risk of duplicate id's. The other issue is to be patched. Shawn Sorry to be paranoid. Can't help it though. On Mon, 2002-12-30 at 23:58, Glenn Olander wrote: You run the risk of getting duplicate session id's. However, across contexts you'll have separate Managers, and therefore different sets of sessions. So, you don't run the risk of one context gaining access to another context's sessions. The risk is the one discussed in the other session id thread where if you get duplicate session id's in the same context. Then you've got serious problems. shawn wrote: If I use RequestDispatcher.forward(request, response) to another context am I running the risk of session id conflicts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- shawn [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
session id's really unique?
If I use RequestDispatcher.forward(request, response) to another context am I running the risk of session id conflicts? I mean if a session Id is given in one context, another context is restarted and the java.security.SecureRandom is re-initialized for that webapp, then it would seem possible that newly generated sessions in the second context could match the previosly generated session id that was transferred from the first context. I doubt I know as much as many on this list, but that is something that I wondered about. Shawn PS I'm relying on potentially outdated info from a list that was posted in response to this topic. Tomcat 4 uses an instance of java.security.SecureRandom to generate session identifiers for a particular session. The instance is initialized the first time (after Tomcat is started, or after a webapp is restarted) that a session identifier is requested. More seriously, it is *you* as the application developer that is deciding whether or not to execute the RequestDispatcher.include() or RequestDispatcher.forward() call -- it's not the container. It is totally up to *you* to decide whether or not this is allowed, because *you* wrote the app. yes I did but will the sessions tranfer uniquely? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
