Shawn Clark (Migrated from SEC-1408) said:
Based on the forum posting I believe there is an issue with the SavedRequest. Here is the flow that I see:
Here is how I think the flow should be:
The reason I see this as a bug is that the SavedRequest would exist on the session while a user navigated around the site and then if they happen to go back to that original page requiring authentication it would pull out the SavedRequest instead of the current Request.
Luke Taylor said:
No, it's not a bug. There are limits to what can be done automatically if you are using your own custom classes, so in Spring Security 3 things are more configurable to allow you more easily control SavedRequest handling. If you are using a custom AuthenticationSuccessHandler and a fixed location, then you should remove the SavedRequest yourself before you do the redirect (see SavedRequestAwareAuthenticationSuccessHandler, which is the default behaviour that you're replacing).
Alternatively, you can set the RequestCache instance used to a NullRequestCache, which will prevent any requests from being saved to start with. You can use the namespace "request-cache" element to do this.
Shawn Clark said:
Thanks for that info and I am now working with my custom handler to remove the SavedRequest. I thought that what I was describing above would happen even without the custom success handler that was built. I do realize now though that the default success handler actually removes the SavedRequest if there is a target url provided as part of the definition.
If there isn't another part of your application which needs the saved request functionality, you might be better just going with the NullRequestCache option.
marc schipperheyn said:
I'm not clear why the RequestCache is not being destroyed in the SavedRequestAwareAuthenticationSuccessHandler after a successful redirect? Since it's a private member, there's also no way to remove it yourself without overriding/copying the entire class