Summary: | Session staying alive across different context paths | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | malini.kesavan |
Component: | Servlet & JSP API | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.91 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Mac OS X 10.1 |
Description
malini.kesavan
2019-06-27 19:15:50 UTC
I think this report is using the term "context path" incorrectly. Web applications on the same host have unique context paths and completely separate session managers (and hence sessions). Therefore, if separate context paths - and hence web applications - were in use then the behaviour described in this report would be impossible. My working assumption is that, in terms of the Servlet spec, context path should be read as HttpServletRequest.getRequestURI(). This can be tested with a default Tomcat install using the examples web application for the requests and the manager web application to monitor session access time. I edited web.xml for the examples web application to use BASIC authentication to match this report. With the default configuration (cache="true") once the session is created, any request to the web application will update the session last accessed time. I'll note at this point that a strict reading of the Servlet specification requires that any access to a web application updates that last accessed time of the associated session irrespective of whether or not the web application explicitly accesses the session. See the org.apache.catalina.core.StandardHostValve.ACCESS_SESSION system property for more details. With cache="false" I can see the issue described. The special handling for FORM auth triggers an update of the session accessed time. It should be possible to refactor that so it only applies with FORM auth is being used. The proposed fix would break FORM authentication. The fix was already present in 8.5.x and 9.0.x. I have back-ported the fix for 7.0.95 onwards. I also back-ported a fair amount of clean-up, refactoring and improved i18n messages as that enabled the fix for this issue to be identified and back-ported cleanly. |