Bug 45921 - Session ID not read from URL when cookie value is not valid
Summary: Session ID not read from URL when cookie value is not valid
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.18
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-30 08:20 UTC by Johnas H.
Modified: 2008-10-01 07:47 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johnas H. 2008-09-30 08:20:51 UTC
Hello,

According to SRV.7.1.3 of the Servlet specs, "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".
Let's now consider the following case:

- A user accesses to an app that creates a session for that user. This means the response will contain a cookie with that session id.
- At some point, the cookie stored into the user's browser might not be valid anymore (let's say we invalidated that session from Tomcat).
- Now imagine that the user (who still has his browser opened, so the cookie is still there) now clicks a link pointing to the same app, but that includes a different (and valid) jsessionid embedded into the URL.

Under this case, the application is receiving a request that contains 2 references to a session: 1 jsessionid coming from a cookie (which is invalid because we manually expired that session from the server) and 1 jsessionid coming from the URL (which is valid because it belongs to a session still active).

When we call request.getSession(true) on the app, Tomcat checks that the jsessionid from the cookie is invalid, and returns a new session. Instead, after verifying that the jsessionid from the cookie is invalid, it should check if there's any valid jsessionid coming through the URL. If so, it should return that session and not create a new one. Apparently, a jsessionid coming through a URL is just considered when there's no jsessionid cookie on the request.

Thanks.
Comment 1 Mark Thomas 2008-10-01 07:47:29 UTC
The fall-back mechanism you describe is not part of the Servlet specification. 

The specification makes clear that URL rewriting is only one possible solution for clients that do not support cookies. Containers are not required to support URL rewriting; they are only required to provide a mechanism to provide session tracking for clients that do not support cookies.

Further, the wording of SRV.7.1.1 indicates that a session ID from a cookie takes priority over one from a url.