DO NOT REPLY [Bug 16822] New: - StandardSession.setId() found incohesive

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16822>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16822

StandardSession.setId() found incohesive

           Summary: StandardSession.setId() found incohesive
           Product: Tomcat 4
           Version: 4.1.18
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: dlr@apache.org


OBSERVED BEHAVIOR: ManagerBase.createSession() calls
StandardSession.setId() as the last thing it does before returning a
newly created session.  StandardSession.setId() exhibits the
undocumented side effect of firing a session creation event, iterating
over all HttpSessionListeners registered with the current web context
and notifying them of its "creation".

A second call to setId() will again fire a session creation event for
the existing session.  Here's some trace from making a single request
when calling setId() explicitly:

2003-02-03 17:46:43,113 [Ajp13Processor[17025][4]] INFO  default - Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of
2EA4840C7D4D6C7F3FF76F1F95C575D5
2003-02-03 17:46:43,175 [Ajp13Processor[17025][4]] INFO  default - Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of
C6C908E127E6230CC81AE70E10D914A4

My web application's list of active sessions (stored as a Map of
StandardSessionFacade objects keyed by session ID) will look as
follows:

Session creation event fired as ManagerBase sets the initial ID by
calling StandardSession.setId() during its createSession() method
              |
              |
              v
.______________________________________.
| Key  | Value                         |
`--------------------------------------'
| ID A | Facade A --> Session A (ID A) |
`--------------------------------------'
              |
              |
Second session creation event fired as SessionIdValve resets the ID,
calling setId() for a second time (this time explicitly).
              |
              |
              v
.______________________________________.
| Key  | Value                         |
`--------------------------------------'
| ID A | Facade A --> Session A (ID A) |
| ID B | Facade A --> Session A (ID B) |
`--------------------------------------'

The entry keyed by session ID A will not be removed from our list of
active sessions when Session A expires, as the session now has an ID
of B.


USE CASE: When creating a new session, I must set the session
identifier (or manipulate it after the initial generation from a
Valve) using request-specific inputs.

Specifically, I must re-use any session identifier supplied by the
client via its JSESSIONID cookie if that session identifier is not
already in use.  Because the Servlet API dictates that the session
cookie is always named JSESSIONID, this is a must have for support of
wildcard cookie domains across hosts which share a common base domain
name.

For instance, if I have host1.domain.com and host2.domain.com, and set
the cookie domain of sessions cookie to the wildcard ".domain.com"
(some pathetic browsers only support two part wildcard domains), the
cookie will apply to both hosts.  This is problematic when a client
which has established a session on host1 tries to establish a second
session on host2 -- host2 will assign the client a new session ID,
wiping the client's memory of its session ID for host1.  Now, if host1
and host2 are gracious enough to use the same session ID, they can
effectively share the JSESSIONID cookie, allowing the client to enjoy
simultaneous sessions on both host1 and host2 while working within the
Servlet API.


PROBLEM: Tomcat's Manager interface has no API for accessing
contextual information specific to a request.  Combining a Valve which
provides this request-specific context via thread-local storage with
my own custom manager is hacky at best, and would require that I
completely re-implement the code in StandardSession (due to its
package-private scoping).

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org