Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-4165

Invalidating another session removes the JSESSIONID cookie of the current session

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 9.0.0.Beta1
    • 8.1.0.Final, 8.2.0.Final
    • Web (Undertow)
    • None
    • WildFly 8.1.0.Final and WildFly 8.2.0.Final on Windows 7 x64
      JDK 8u25
      Session storage set to Cookie

    • Hide
      1. Store in an @ApplicationScoped managed bean for example an HttpSession instance
      2. In another request, call invalidate() on that HttpSession instance
      3. Notice the "Set-Cookie" header in the response, discarding the cookie of the current session
      Show
      Store in an @ApplicationScoped managed bean for example an HttpSession instance In another request, call invalidate() on that HttpSession instance Notice the "Set-Cookie" header in the response, discarding the cookie of the current session

      When calling invalidate() on a HttpSession object of another session than the current one, the server sends back a "cookie expired" header Set-Cookie: JSESSIONID=XXXXXXXX; path=/; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT where XXXXXXXX is the session id of the invalidated session.
      This results in the current JSESSIONID cookie being discarded by the browser, and the current session being lost.

      I was able to narrow the "problem" in io.undertow.servlet.spec.HttpSessionImpl:193 (in Undertow 1.0.15.Final), where the ServletRequestContext is taken from the ThreadLocal storage, returning the current request context instead of null (as the target session is not associated to the current ServletRequestContext )

      A workaround is to call invalidate() in a new Thread, so the retrieved ServletRequestContext is null

              sdouglas1@redhat.com Stuart Douglas (Inactive)
              neo1203 Nicolas Grussenmeyer (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: