Keith Donald (Migrated from SEC-1471) said:
My use case:
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.
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/
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.
This issue supersedes #772