Uploaded image for project: 'XNAT'
  1. XNAT
  2. XNAT-4573

XNAT has issues with user sessions and redirection when logging in to uninited XNAT

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7.1
    • Component/s: None
    • Labels:
      None
    • Sprint:
      1.7.1 Release Sprint 1
    • Rank:
      0|ii12rb:
    • Sprint:
      1.7.1 Release Sprint 1

      Description

      Build a dev server. Wait 10 minutes. Try to log in. The thing that's most likely to happen is you get redirected to the login page. Other issues around this is sometimes the server traps you in a redirect loop of /setup -> /setup/ -> /setup -> ... Also, if you do a failed login, then log in normally directly afterward, it seems to reach the setup page just fine. Very strange.

        Issue Links

          Activity

          Hide
          jrherrick@wustl.edu Rick Herrick added a comment -

          Issue is that an extra session ID, which is not associated with an authenticated session, is created under some circumstances:

          1. Browser POSTs to /login with session ID A, which is not associated with authenticated session.
          2. Server responds with redirect to root URL and sets session ID B, which is associated with authenticated session.
          3. Browser requests GET for /style/icons/icon-info-48.png with session ID A.
          4. Under normal circumstances, server responds with 200 and sets the SESSION_EXPIRATION_TIME cookie. Under circumstances where login fails, server also sets session ID C, which is not associated with authenticated session.
          5. Browser follows redirect to root URL from before icon request, still using session ID B.
          6. Server responds with 302 to /setup.
          7. Browser follows redirect to /setup, but this time using session ID C (no authentication).
          8. Server redirects to /setup/.
          9. Browser follows redirect to /setup/, still using session ID C (no authentication).
          10. Server responds with 302, redirecting to http://xnatdev.xnat.org/app/template/Login.vm.

          At this point, there are two active session IDs for the browser. One is associated with an authenticated session, but is no longer being used by the browser. The other is not associated with
          an authenticated session and is being used by the browser.

          Once you go back to the login page, you can add "?failed=true" to the URL and login successfully. The icon that causes the trouble is being requested during that transaction.

          Show
          jrherrick@wustl.edu Rick Herrick added a comment - Issue is that an extra session ID, which is not associated with an authenticated session, is created under some circumstances: Browser POSTs to /login with session ID A, which is not associated with authenticated session. Server responds with redirect to root URL and sets session ID B, which is associated with authenticated session. Browser requests GET for /style/icons/icon-info-48.png with session ID A. Under normal circumstances, server responds with 200 and sets the SESSION_EXPIRATION_TIME cookie. Under circumstances where login fails, server also sets session ID C, which is not associated with authenticated session. Browser follows redirect to root URL from before icon request, still using session ID B. Server responds with 302 to /setup. Browser follows redirect to /setup, but this time using session ID C (no authentication). Server redirects to /setup/. Browser follows redirect to /setup/, still using session ID C (no authentication). Server responds with 302, redirecting to http://xnatdev.xnat.org/app/template/Login.vm . At this point, there are two active session IDs for the browser. One is associated with an authenticated session, but is no longer being used by the browser. The other is not associated with an authenticated session and is being used by the browser. Once you go back to the login page, you can add "?failed=true" to the URL and login successfully. The icon that causes the trouble is being requested during that transaction.
          Hide
          jrherrick@wustl.edu Rick Herrick added a comment -

          When login page posts credentials to /login, Spring Security invalidates the existing JSESSIONID and immediately creates a new session. It then adds the user principal to that new session and responds to the user with a Set-Cookie with the new JSESSIONID.

          The problem is caused by another request that comes in immediately after the /login request. That request uses the old JSESSIONID. Since that session is now invalidated, Tomcat responds with a new JSESSIONID. That session is not associated with the session that contains the user principal, i.e. it's unauthenticated. This Set-Cookie directive comes after the one that contains the session ID associated with the session, so the browser loses the session.

          The immediate solution for this issue was to remove the object that was being requested on that second request. It was a graphic referenced in app.css. Something must have gotten the class that referenced the icon set on it and so the graphic required for the class was requested. To eliminate that request, all graphics in app.css were converted from url(/path/to/graphic.png) to url(data:image/png;base64,xxx).

          Show
          jrherrick@wustl.edu Rick Herrick added a comment - When login page posts credentials to /login, Spring Security invalidates the existing JSESSIONID and immediately creates a new session. It then adds the user principal to that new session and responds to the user with a Set-Cookie with the new JSESSIONID. The problem is caused by another request that comes in immediately after the /login request. That request uses the old JSESSIONID. Since that session is now invalidated, Tomcat responds with a new JSESSIONID. That session is not associated with the session that contains the user principal, i.e. it's unauthenticated. This Set-Cookie directive comes after the one that contains the session ID associated with the session, so the browser loses the session. The immediate solution for this issue was to remove the object that was being requested on that second request. It was a graphic referenced in app.css. Something must have gotten the class that referenced the icon set on it and so the graphic required for the class was requested. To eliminate that request, all graphics in app.css were converted from url(/path/to/graphic.png) to url(data:image/png;base64,xxx).
          Hide
          moore.c@wustl.edu Charlie Moore added a comment -

          I guess we'll call this one closed? (still scary, though...)

          Show
          moore.c@wustl.edu Charlie Moore added a comment - I guess we'll call this one closed? (still scary, though...)

            People

            • Assignee:
              moore.c@wustl.edu Charlie Moore
              Reporter:
              moore.c@wustl.edu Charlie Moore
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week
                1w

                  Agile