Spring Security
  1. Spring Security
  2. SEC-1408

SavedRequest not being removed after login (on redirection to another page)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.0.2
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Spring tc Server Developer Edition, Spring 3.0.0.RELEASE, Spring Security 3.0.1.RELEASE

      Description

      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.

        Activity

        Hide
        Luke Taylor added a comment - - edited

        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.

        Show
        Luke Taylor added a comment - - edited 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.
        Hide
        Shawn Clark added a comment -

        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 <form-login /> definition.

        Show
        Shawn Clark added a comment - 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 <form-login /> definition.
        Hide
        Luke Taylor added a comment - - edited

        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.

        Show
        Luke Taylor added a comment - - edited 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.
        Hide
        marc schipperheyn added a comment -

        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

        Show
        marc schipperheyn added a comment - 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

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Shawn Clark
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: