AW: Session ID's
Well, nobody likes to go through the specs, an excellent book which covers the session handling very well to is: Head First Servlets and JSP http://www.amazon.com/exec/obidos/tg/detail/-/0596005407/qid=1123053380/sr=8 -1/ref=pd_bbs_sbs_1/103-1556156-2935038?v=glances=booksn=507846 Bernhard -Ursprüngliche Nachricht- Von: Charles P. Killmer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. August 2005 19:08 An: Tomcat Users List Betreff: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Session ID's
I second that book recommendation, I think every Java web developer should have in on their desk. At times it can be a little TOO light-hearted, but it never fails to get the pertinent information across in a very understandable way. Probably shouldn't be the ONLY book on ones' desk, but it is very good. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, August 3, 2005 3:18 am, Bernhard Slominski said: Well, nobody likes to go through the specs, an excellent book which covers the session handling very well to is: Head First Servlets and JSP http://www.amazon.com/exec/obidos/tg/detail/-/0596005407/qid=1123053380/sr=8 -1/ref=pd_bbs_sbs_1/103-1556156-2935038?v=glances=booksn=507846 Bernhard -Ursprüngliche Nachricht- Von: Charles P. Killmer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. August 2005 19:08 An: Tomcat Users List Betreff: 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] - 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]
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
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]
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]
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]
Session ID's
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
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]
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]
