Yes indeed, Catalysts has moved, but that doesn’t mean we are gone, we just moved to our new website
together with our partners from Crisp Research to do the same things we used to do in an improved way. We still do great software and we are still great people, more or less only the color has changed except from our domain 😉

Maintain HTTPSession in Spring Security Applications

No Comments

We’re just doing some GWT applications and use Spring Security on server side for authentication and authorization.

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

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 cc_server_gwt/myService.rpc, where cc_server_gwt is the subdirectory that contains the generated JavaScript files. This also URL matches the only rule that we have defined above in our 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 security-context.xml:


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

Previous Post
Catalysts-Update April 2010
Next Post
Relavitivätstheorie für Seminare

Related Posts

Highly available webapps with Java and Spring – Part 1

High availability and fault tolerance are frequently important requirements for customers. By thinking ahead and using the right technologies we at Catalysts can fulfill these requirements to boost your products performance and ensure productivity.

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed