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:
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.
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.
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.
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
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.