Announcement Announcement Module
Collapse
No announcement yet.
Sessionless: auth cookies disappear after Spring Security authentication completes Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sessionless: auth cookies disappear after Spring Security authentication completes

    Summary:
    We're using a sessionless 3.0.5 configuration whereby the auth token, user ID, and security context are stored in 3 cookies. By the time the request makes it through Spring Security to the mapped controller the cookies are missing from the request yet they still exist in the browser.


    More details:
    0) User is unauthenticated (and thus has 0 of our cookies)
    1) User types in address of authenticated page (e.g "theirDestinationPage")
    2) We've subclassed LoginUrlAuthenticationEntryPoint and overridden addTargetParamToUrl() to direct the unauthenticated user to the login page with an appended "?spring-security-redirect=theirDestinationPage". A JSESSIONID is also assigned.
    3) User submits the form which is validated by jQuery and then a $.post() submits those credentials and our AuthenticationFilter kicks in.
    4) A status code is returned that tells jQuery if the user is authenticated or not. If user is authenticated then 3 cookies are also returned on the response and the user is then allowed to visit any authenticated page. The jQuery callback function then sets top.location.href to equal the value of spring-security-redirect and uses a default dashboard as the fallback landing page.
    5) Now the user is authenticated and the GET on "theirDestinationPage" has been issued.
    5) Within the scope of our ContextRepository I can see that request.getCookies() returns the expected 3 auth cookies and 1 JSESSIONID.
    6) Throughout the ensuing Spring Security lifecycle the cookies exist but when the request hits the controller mapped to "theirDestinationPage" the 3 cookies are missing from the request (including the JSESSIONID).
    7) If the user then does a GET on the theirDestination URL (which is in the address bar already thanks to jQuery), then the controller of that same authenticated page that failed before can now see the cookies and loads normally. Subsequent GETs also succeed as this one did until the session times out as expected.


    Is there anything special that we need to do to retain those cookies in this sessionless configuration until the request reaches the intended controller in step 6?


    Thanks very much for any assistance!
    Chris

  • #2
    The normal flow is to use a cached version of the original request which is re-created using a wrapper after the user has logged in. The ExceptionTranslationFilter will store the If you aren't using this then you should disable the request caching (e.g by using a NullRequestCache implementation instead of the default session-based store).

    Presumable you don't actually want a session to be created if your app is intended to be stateless.

    Comment


    • #3
      Originally posted by koose View Post
      2) We've subclassed LoginUrlAuthenticationEntryPoint and overridden addTargetParamToUrl() to direct the unauthenticated user to the login page with an appended "?spring-security-redirect=theirDestinationPage". A JSESSIONID is also assigned.
      Also, I don't quite get what you mean here. I'm not aware of a method called addTargetParamToUrl(). That parameter normally should only be relevant to login page submission, rather than the login page itself.

      Comment


      • #4
        Thanks Luke for the quick replies. The nullRequestCache did the trick!

        Yeah, you're correct in that I had a typo in my post about addTargetParamToUrl() -- that was a custom method that we created. To capture the user's intended destination we override LoginUrlAuthenticationEntryPoint to save the target parameter value in the URL. It happened to have been named spring-security-redirect but should have been named something else to prevent confusion (it was a leftover artifact from a past implementation). This parameter is not submitted to Spring during login but simply used after a successful auth response from Spring Security so that jQuery can perform a GET on that target page.

        Comment

        Working...
        X