AW: Session ID's

-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

Re: AW: Session ID's

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

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

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

Re: Session ID's

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

AW: Session ID's

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

RE: Session ID's

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

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

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

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

Re: Session ID's

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

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

Re: session id's really unique?

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

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