Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1471: Session-based request playback can fail when multiple windows share the same session #1710

spring-issuemaster opened this Issue Apr 28, 2010 · 5 comments


None yet
1 participant

Keith Donald (Migrated from SEC-1471) said:

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.

Luke Taylor said:

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

Luke Taylor said:

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

Keith Donald said:

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

Luke Taylor said:

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.

@spring-issuemaster spring-issuemaster added this to the 3.1.0.M1 milestone Feb 5, 2016

This issue supersedes #772

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment