Spring Security
  1. Spring Security
  2. SEC-1735

Logged out immediately after logging in on some browsers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.5, 3.1.0
    • Fix Version/s: 3.0.8, 3.1.1
    • Component/s: Web
    • Labels:
      None
    • Environment:
      Tomcat 6, MyFaces 2.0.X, Richfaces 4.0.0.Final.
      Internet Explorer as client

      Description

      This bug is closely related to SEC-1587.
      I start at my log in screen, log into the system, see the logged in view and then the next navigation I make I end up being redirect back to the login screen.
      It happens periodly, not every time. It happens the most when using Internet Explorer 6.
      After I debugged the problem I figured out that the httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); call in HttpSessionSecurityContextRepository was destroying my newly created authentication object.
      Here's how it happens:
      1. Browser requests jsf.js.faces during the loading of the login screen. This request passes through the httpSessionContextIntegrationFilter along with all .faces requests.
      2. Browser holds on to connection after getting the javascript file. (Browsers do this as an optimization to prevent lots of new tcp connects)
      3. I log into my app from the login page. This adds the security context to the session.
      4. Browser makes another javascript request from the open connection which causes the thread working on jsf.js.faces to finish up (come back out through the filters)
      5. On the request thread of jsf.js.faces the original security context had a null authenication so httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); is called which wipes up the new authenication.

      I've worked around the problem by created my own version of HttpSessionSecurityContextRepository and just changing the lines:
      if (httpSession != null)

      { // SEC-1587 A non-anonymous context may still be in the session httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); }
      return;

      to

      if (httpSession != null && contextHashBeforeChainExecution != -1) { // SEC-1587 A non-anonymous context may still be in the session httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); }

      return;

      This means that the security context is only reset if there was one at the beginning of the request. (Hash of -1 means no authenication)

        Activity

        Hide
        Rob Winch added a comment -

        In general I can see how this would happen.

        1) The login page loads and makes an asynchronous request (i.e. javascript, css, image, etc)
        2) In the meantime, a user submits their credentials before the asynchronous request completes
        3) After the user has logged in, the asynchronous request (with anonymous authentication) completes and removes the authentication established in #2.

        Can you confirm that this is a generalization of what is happening?

        Show
        Rob Winch added a comment - In general I can see how this would happen. 1) The login page loads and makes an asynchronous request (i.e. javascript, css, image, etc) 2) In the meantime, a user submits their credentials before the asynchronous request completes 3) After the user has logged in, the asynchronous request (with anonymous authentication) completes and removes the authentication established in #2. Can you confirm that this is a generalization of what is happening?
        Hide
        James G added a comment -

        Yes, that is exactly it. I just want to point out that ie6 seems to prevent the completion of some asynchronous requests until it reuses the connection to do another request. (for example load another javascript file).
        Thank you.

        Show
        James G added a comment - Yes, that is exactly it. I just want to point out that ie6 seems to prevent the completion of some asynchronous requests until it reuses the connection to do another request. (for example load another javascript file). Thank you.
        Hide
        Markus Siegel added a comment -

        i got the same problems with Tomcat 6 and Icefaces 1.8 in every browser. In the moment im using also the workaround.

        Show
        Markus Siegel added a comment - i got the same problems with Tomcat 6 and Icefaces 1.8 in every browser. In the moment im using also the workaround.
        Hide
        Rob Winch added a comment -

        Thanks for the bug submission. I have pushed a fix to master and the 3.0.x branch. The fix I checked in is a bit different than the orional proposal to ensure it works with other implementations of SecurityContexts.

        Show
        Rob Winch added a comment - Thanks for the bug submission. I have pushed a fix to master and the 3.0.x branch. The fix I checked in is a bit different than the orional proposal to ensure it works with other implementations of SecurityContexts.

          People

          • Assignee:
            Rob Winch
            Reporter:
            James G
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: