RE: Session ID's
Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session ID's
I was hoping there was a configuration setting that would tack the session id onto every hyperlink at runtime, much as PHP does. Charles -Original Message- From: Derrick Koes [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:20 AM To: Tomcat Users List Subject: RE: Session ID's Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - 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]
Re: Session ID's
That wouldn't make much sense IMO. What about links to external hosts or to different contexts on the same host? It would be a security hole to give them your session id. (One could handle this partly by only applying the rewrite to relative URLs) What about links to images, css, javascript files? They would get the session id and therefore unnecessarily not be cached by the users browser. I'm curious: do you know how PHP handles these issues? Christoph Charles P. Killmer wrote: I was hoping there was a configuration setting that would tack the session id onto every hyperlink at runtime, much as PHP does. Charles -Original Message- From: Derrick Koes [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:20 AM To: Tomcat Users List Subject: RE: Session ID's Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session ID's
PHP handles only relative links. It ignores the src= and only applies to href and also creates a hidden field for forms. Charles -Original Message- From: Christoph Kutzinski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:24 AM To: Tomcat Users List Subject: Re: Session ID's That wouldn't make much sense IMO. What about links to external hosts or to different contexts on the same host? It would be a security hole to give them your session id. (One could handle this partly by only applying the rewrite to relative URLs) What about links to images, css, javascript files? They would get the session id and therefore unnecessarily not be cached by the users browser. I'm curious: do you know how PHP handles these issues? Christoph Charles P. Killmer wrote: I was hoping there was a configuration setting that would tack the session id onto every hyperlink at runtime, much as PHP does. Charles -Original Message- From: Derrick Koes [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:20 AM To: Tomcat Users List Subject: RE: Session ID's Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - 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] - 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]
RE: Session ID's
Thanks. I will take a look through this. Charles -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:33 AM To: 'Tomcat Users List' Subject: AW: Session ID's Some small addition: URL Rewriting is only used when cookies are switched off. From the Servlet Spec: SRV.7.1.3 URL Rewriting URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session. The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information: http://www.myserver.com/catalog/index.html;jsessionid=1234 SRV.7.1.4 Session Integrity Web containers must be able to support the HTTP session while servicing HTTP requests from clients that do not support the use of cookies. To fulfill this requirement, Web containers commonly support the URL rewriting mechanism. Bernhard -Ursprüngliche Nachricht- Von: Charles P. Killmer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. August 2005 17:03 An: Tomcat Users List Betreff: RE: Session ID's I was hoping there was a configuration setting that would tack the session id onto every hyperlink at runtime, much as PHP does. Charles -Original Message- From: Derrick Koes [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:20 AM To: Tomcat Users List Subject: RE: Session ID's Use HttpServletResponse.encodeURL(String url) -Original Message- From: Charles P. Killmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 10:04 AM To: Tomcat Users List Subject: Session ID's Is there a configuration setting such that every local URL will be encoded with a session id if one is present? I have developed a site that uses cookies to hold the session id and am getting complaints from users that do not have cookies enabled. Thanks Charles - 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] - 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]
Re: Session ID's
See the tomcat-dev archives. There was a big discussion many months ago about duplicate session ids and the chance for a dup id. -Tim Marc Hughes wrote: I'm curious, will a tomcat instance ever create duplicate session ID's? And I mean *ever*, so if I run a server for 5 years (with multiple reboots, etc.) will I ever get a duplicate session ID? If so what's the frequency it would happen? Every million, billion, 10 trillion? Does the situation change if I have a cluster of tomcat servers? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session ID's
Well, of course you will someday, it's still a finite-state machine ;-). The current TC 4/5 implementation has (if I've done the math right :) about 8E28 possible session values, so necessarily you will get a repeat after you generate that many sessions. The id is generated by SecureRandom, so the expected time for a repeat is pretty large. In addition, TC 5 uses /dev/urandom to generate the seed, so the time should be even longer than with TC 4. Marc Hughes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm curious, will a tomcat instance ever create duplicate session ID's? And I mean *ever*, so if I run a server for 5 years (with multiple reboots, etc.) will I ever get a duplicate session ID? If so what's the frequency it would happen? Every million, billion, 10 trillion? Does the situation change if I have a cluster of tomcat servers? Thanks! -Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
