|Summary:||Servlet called with cross-context request can access a stale session|
|Product:||Tomcat 6||Reporter:||Konstantin Kolinko <knst.kolinko>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
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.