Maintain HTTPSession in Spring Security Applications

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 means, 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:

<http use-expressions="true">
   <intercept-url pattern="/"/>
   <form-login />
   <logout />
</http>

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 finds 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 URL matches only the 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 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:

<http use-expressions="true">
   <intercept-url pattern="/"/>
   <intercept-url pattern="/cc_server_gwt/**" filter="none"/>
   <form-login />
   <logout />
</http>

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.

 

Vorheriger Beitrag
Catalysts-Update April 2010
Nächster Beitrag
Relavitivätstheorie für Seminare

Related Posts

JPF Part 1 – A lightweight alternative to OSGi?

When developing web applications it has always been a challenge how to plug in customer specific extensions and integrations without invading the inner guts of the web application too much. This not only concerns the source code, it is quite easy to keep customer specific sources out of the application’s trunk, the main problems usually arise when thinking about deployment strategies

Weiterlesen

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.

Weiterlesen

Highly available webapps with Java and Spring – Part 2

Catalysts even open sources many useful libraries. This way you can benefit from our learnings and can get a sneak peek at our practices and technologies.

Weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren

Menü