SEC-1408: SavedRequest not being removed after login (on redirection to another page) #1653

Closed
spring-issuemaster opened this Issue Feb 11, 2010 · 4 comments

1 participant

@spring-issuemaster

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:

  1. Request to page requiring authentication
  2. Request is saved and user is redirected to login
  3. User completes the login and is then redirected to another page (not the page they were originally trying to get that required authentication)
  4. User goes back to the page that was requiring authentication.
  5. SavedRequest is used instead of the incoming request.

Here is how I think the flow should be:

  1. Request to page requiring authentication
  2. Request is saved and user is redirected to login
  3. User completes the login and is then redirected to another page (not the page they were originally trying to get that required authentication)
  4. On request of a page that is not the original page the SavedRequest should be removed from the session
  5. User goes back to the page that was requiring authentication.
  6. No SavedRequest exists on the session so the current Request is used.

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.

@spring-issuemaster

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.

@spring-issuemaster

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.

@spring-issuemaster

Luke Taylor said:

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.

@spring-issuemaster

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

@spring-issuemaster spring-issuemaster added this to the 3.0.2 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment