Generally that all works fine, but recently I’ve spent some hours finding out an issue with http sessions. Spring Security’s
HttpSessionSecurityContextRepository is responsible to connect a
SecurityContext with the current HTTP session. That mean’s, if you once login to your application via Spring Security, the framework stores the session information as parameter
SPRING_SECURITY_CONTEXT. If you later reload your browser window by pressing F5, the HTTP session is still there, Spring Security can recover the
SecurityContext and populate the currently logged in user to the
So far so good.
In our GWT applications we use JSON and RPC requests and those requests do not contain the HTTP session information. Now our
security-context.xml looked something like that:
That means basically we’re intercepting all calls. Our main page (
index.jsp) which launches the GWT client comes from the root page, Spring Security looks for the HTTP session and if it founds one, it logs in that user. Then the GWT client comes up and launches some RPC requests. The URL for those requests is something like
security-context.xml and thus the
FilterChainProxy calls all registered filters to process the request. Now we come to the
HttpSessionSecurityContextRepository again, which recognizes that a request was launched to that page without a valid http session information and then clears its context repository. After that, if I press F5 in the browser, the server side has no connection to between HTTP Session and SecurityContext any more and therefore is not able to reuse the session. Our solution to fix that problem was to simply ignore all RPC calls in the
FilterChainProxy is not called for RPC requests (which makes request processing on the server side much faster as well) and the
HttpSessionSecurityContextRepository cannot discard the session information for the SecurityContext.
Finally, reloading the client with F5 while being logged in works again.