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?