Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-2027: FilterChainProxy clearing context causes forwards to clear authentication from the session #2252

spring-issuemaster opened this Issue Aug 7, 2012 · 8 comments


None yet
2 participants

Eric Tucker (Migrated from SEC-2027) said:

SEC-1950 added a finally block to the FilterChainProxy doFilter method.

As a result, it seems that when attempting to render a model and view, the forward from tomcat (using 7.0.28) to get the JSP will be allowed. However, when the SecurityContextPersistenceFilter calls saveContext from its doFilter method, the context is removed from the session as the context after chain execution now has a null authentication object.

With a second forward in place (using sitemesh) the attempt to get the decorator JSP is denied and the user is redirected back to the login page.

I debugged under eclipse, put a break point at the following:

  • doFilter in the security context persistence filter
  • wrapRequest (tomcat - ApplicationDispatcher) -> forward
  • save context (from the finally block of do filter of security context persistence filter)


  • do filter is called, which then calls chain.doFilter to continue the chain after creating the session
  • wrap request is called (signalling the forward is occuring to get the jsp)
  • save context is then called which removes the context from the session as it now has a null authentication object

The next request is redirected back to the login page since no authentication attribute exists in the session.

Reverted to spring security 3.1.0 and things work fine.

I have a hard time believing that the change under SEC-1950 was implemented without attempting to render a single model and view, so this may be something funky about our application. However, given that reverted to 3.1.0 allows everything to function correctly, I figured it was worth creating this issue.

Of note: our JSPs are located in our web application as opposed to statically served so they required authentication. Perhaps this is abnormal configuration?

Rob Winch said:

Thank you for taking the time to report this issue. The bug appears to be related to when using a that processes FORWARD's as shown below. Can you confirm this is something the application in is doing?


Typically Spring Security is only used on REQUEST and is not necessary to process forwards. Most developers protect the JSP by placing it in the WEB-INF directory and protecting the URLs that process the REQUEST prior to the FORWARD. This is not to say that this does not need fixed, but this is why it was not discovered until now.

Eric Tucker said:

We have that plus dispatchers for ERROR and INCLUDE (we're eager about security).

Is the work around to remove having a dispatcher on FORWARDs? I am currently working on upgrading from spring security 2.x to 3.x for our application, so I did not code the original configuration with a dispatcher on FORWARDs. This could be an unnecessary thing (I'll have to verify when I get into work tomorrow).

Right now it works under 3.1.0, but SEC-1950 talked about memory leaks which I do not want creeping up in the application.

Rob Winch said:

Thank you for your prompt response and confirming how this occurs. SEC-1950 is more about defensive programming in the event a developer accesses the SecurityContext on URLs that the SessionManagementFilter is not invoked (i.e. If SecurityContext.getContext() is called for a URL that matches security="none" it will not get cleared out). In general, this should not be a problem but it helps developers from making these types of programming errors.

The work around for now is to use 3.1.0.RELEASE. However, I have already pushed out a fix and it will be included in the 3.1.2.RELEASE which should be out later this week. You can keep an eye out for the release announcement on the Spring Security forums, twitter @SpringSecurity, or the news feed on http://springsource.org.

Eric Tucker said:

I had an http element defined for our login page with security="none". I have since changed it to use an intercept-url tag inside the main http tag for the login page and used the anonymous tag along with IS_AUTHENTICATED_ANONYMOUSLY to allow the login page to be served up without authentication.

I'll have to proceed with 3.1.0 for now due to time constraints, but I do appreciate the quick response and action. Thank you.

Rob Winch said:

No problem. Just to emphasize that the security="none" would only cause problems if you also had code accessing the SecurityContextHolder.getContext() method. Sometimes this can be a bit tricky to detect (i.e. if you use the taglib it will do it) so using the anonymous authentication is probably preferred. I generally only recommend the security="none" approach for static resources (i.e. css, javascript, images, etc).

The update from 3.1.0 to 3.1.2 should be as easy as updating the version of jars you pull in so hopefully this won't set you back too much. Thanks again for reporting the issue and being so responsive (it helps to get things fixed faster).

Farrukh Najmi said:

I am seeing a similar problem as reported at:


Here are my versions for spring modules:


Does this look like the same issue?

Rahul Shivhare said:

I have also same problem... pls figure out spring versions

org.springframework spring-webmvc 3.1.3.RELEASE org.springframework.security spring-security-core 3.1.0.RELEASE org.springframework.security spring-security-config 3.1.0.RELEASE org.springframework.security spring-security-web 3.1.0.RELEASE org.springframework spring-orm 3.1.0.RELEASE

Rob Winch said:

This has been fixed in Spring Security 3.1.2.RELEASE+. Please try updating to the latest version of Spring Security 3.2.5.RELEASE. The release is passive and should not cause you to do anything but change your pom files.

@spring-issuemaster spring-issuemaster added this to the 3.1.2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment