Summary: | Race Condition in HttpSession#invalidate() / HttpServletRequest#getSession(boolean) | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Christoph <christoph.ludwig> |
Component: | Servlet & JSP API | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.40 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: | code flow that exhibits the race condition |
Description
Christoph
2013-09-04 10:24:05 UTC
I've taken a look at this and there are some things we can do in Tomcat to ensure that a call to invalidate() doesn't return until the session has been invalidated. However, there may still be an issue that needs fixing in Spring Security. Looking at SessionFixationProtectionStrategy.applySessionFixation() it is possible (although even less likely than the issue you have seen) for concurrent requests to generate a series of invalidate / create / invalidate / create etc. events. It is pretty unlikely but is possible. Since I work for Pivotal, I'll ping one of the developers. Mark, it would be great if you'd ask one of your colleagues to take a look at the additional issues in Spring Security you observed. As far as Tomcat is concerned, the race condition I observed would no longer exist if the early check of the expiring field before the synchronized block is entered would be removed. Of course, I don't now whether this check is merely the result of an over-eager optimization or whether it is needed in some situation I am not aware of. Thsi has been fixed in trunk and 7.0.x and will be included in 8.0.0-RC2 and 7.0.43 onwards. Thanks for the very prompt fix! Regards Christoph |