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
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
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
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
-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
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
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
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
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
