Bug 49245 - Servlet called with cross-context request can access a stale session
Servlet called with cross-context request can access a stale session
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.26
PC Windows XP
: P2 minor (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-05-04 06:57 UTC by Konstantin Kolinko
Modified: 2010-05-04 07:12 UTC (History)
0 users



Attachments
webapps.zip (4.17 KB, application/x-download)
2010-05-04 06:57 UTC, Konstantin Kolinko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2010-05-04 06:57:31 UTC
Created attachment 25396 [details]
webapps.zip

When a servlet is called using cross-context forward/include call from another web application, its call to request.getSession(boolean) may return a session which was inactive for longer than configured session-timeout.

This issue was fixed in trunk in r926716

To reproduce:
1. Unzip the attached archive and deploy the two web applications contained there, "expire" and "expireB". "expireB" is configured to have session-timeout of one minute.
2. Access http://localhost:8080/expire/
The index.jsp page there will print current time and will display two sessions from both web applications.
3. Wait for 65-70 seconds and once more access http://localhost:8080/expire/
You may see the following output:
[[[
Current time: Tue May 04 14:44:16 MSD 2010

expire/index.jsp: Session:
id: 6124AB5790D0ABF2CD6472D63EE5332D
isNew: false
getCreationTime: Tue May 04 14:43:04 MSD 2010
getLastAccessedTime: Tue May 04 14:43:04 MSD 2010

expireB/index.jsp: Session:
id: 6124AB5790D0ABF2CD6472D63EE5332D
isNew: false
getCreationTime: Tue May 04 14:43:05 MSD 2010
getLastAccessedTime: Tue May 04 14:43:05 MSD 2010
]]]

Current time is 14:44:16 which is more that 1 minute more than lastAccessedTime of expireB session, 14:43:05. Observed: "expireB" reuses an old session. Expected: to use a new session (isNew: true) in "expireB".


I think this issue is a minor one, because it looks as the effective value for session-timeout configuration option is slightly greater that its literal value:

1) I observed no problems with the session. Even if the session was a stale one, session.access() call prolongs its lifetime. There was no IllegalStateException when calling its methods.

2) There is a background thread that cleans stale sessions once in several minutes (calls ManagerBase#processExpires()). This limits the difference between effective and literal values of session-timeout.
Comment 1 Konstantin Kolinko 2010-05-04 07:12:50 UTC
Fixed in 6.0 in r940804 and will be in 6.0.27 onwards.