Spring Security
  1. Spring Security
  2. SEC-1471

Session-based request playback can fail when multiple windows share the same session

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.1.0.M1
    • Component/s: None
    • Labels:
      None

      Description

      My use case:

      • Two brower windows are open. One displaying a secure page that is doing some Ajax polling. Another displaying the application index page.
      • Suppose on the index page I click "Sign Out". The poller running on the secure page continues to poll, but it's now receiving authentication entry point redirect responses (since I'm no longer authenticated). This particular poller expects JSON content, so it is ignoring the HTML content generated by following the sigin-in redirect.
      • Now lets say I access a secure page from the window displaying the index page by clicking a secure link. I'm not authenticated, so I get redirected to the sign-in page. All is good. However, after login, I get erroneously redirected back to the poller's resource (/messages) URL instead of the secure link I selected, because it was the last request to be executed in that session. In my app, I actually get a Download dialog for a JSON file, which is obviously not correct. Closing the window doing the polling resolves the problem when I try to re-authenticate.

      The problem here seems to be use of session scope for storage of the last request when multiple windows are open concurrently.

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment -

          I don't see any other option apart from storing the request in the session. The saved-request handling has always been a "best effort" approach and changes were made in Spring Security 3 to make it more customizable, in recognition of the fact that the default setting doesn't cater for all use cases. The interface which is invoked to store and retrieve saved requests is RequestCache, with the default implementation being HttpSessionRequestCache. A custom version can be substituted using the <request-cache /> element in the namespace. The most obvious solution here would be to use a RequestCache which ignores requests to the "/messages" URL.

          It might also make sense to use a custom DelegatingAuthenticationEntryPoint with an Http403ForbiddenEntryPoint for the Ajax parts of the application and a normal LoginUrlAuthenticationEntryPoint for the browser-based parts. That would prevent redirects being sent to the JSON poller.

          Show
          Luke Taylor added a comment - I don't see any other option apart from storing the request in the session. The saved-request handling has always been a "best effort" approach and changes were made in Spring Security 3 to make it more customizable, in recognition of the fact that the default setting doesn't cater for all use cases. The interface which is invoked to store and retrieve saved requests is RequestCache, with the default implementation being HttpSessionRequestCache. A custom version can be substituted using the <request-cache /> element in the namespace. The most obvious solution here would be to use a RequestCache which ignores requests to the "/messages" URL. It might also make sense to use a custom DelegatingAuthenticationEntryPoint with an Http403ForbiddenEntryPoint for the Ajax parts of the application and a normal LoginUrlAuthenticationEntryPoint for the browser-based parts. That would prevent redirects being sent to the JSON poller.
          Hide
          Luke Taylor added a comment -

          I should add that we could facilitate the ability to apply the RequestCache to particular requests by making it configurable with a RequestMatcher instance.

          Show
          Luke Taylor added a comment - I should add that we could facilitate the ability to apply the RequestCache to particular requests by making it configurable with a RequestMatcher instance.
          Hide
          Keith Donald added a comment -

          The sample app that experiences this issue is here: https://src.springframework.org/svn/spring-samples/petcare/trunk/

          Show
          Keith Donald added a comment - The sample app that experiences this issue is here: https://src.springframework.org/svn/spring-samples/petcare/trunk/
          Hide
          Luke Taylor added a comment -

          I've added support for injecting a RequestMatcher instance into HttpSessionRequestCache, to allow more control over which requests will be saved by the ExceptionTranslationFilter. Combined with some of the other options mentioned above, as necessary, it should be possible to satisfy most application requirements.

          Note that the justUseSavedRequestOnGet property (SEC-516, SEC-1167) has been removed as this should no longer be necessary now that full-control over which requests are stored is available.

          Show
          Luke Taylor added a comment - I've added support for injecting a RequestMatcher instance into HttpSessionRequestCache, to allow more control over which requests will be saved by the ExceptionTranslationFilter. Combined with some of the other options mentioned above, as necessary, it should be possible to satisfy most application requirements. Note that the justUseSavedRequestOnGet property ( SEC-516 , SEC-1167 ) has been removed as this should no longer be necessary now that full-control over which requests are stored is available.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Keith Donald
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: