Is it valid to call session.invalidate() as part of request.logout()? (via custom extension)

[psiroky]

Hello everyone,

we are facing an issue when using the combo "request.logout() + session.invalidate()" as part of the "logout" servlet. We are using WF 10.1.0.Final / EAP7.

The code looks like this:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

        request.logout();

        HttpSession session = request.getSession(false);

        if (session != null) {

            session.invalidate();

        }

        // ....

    }

This works fine without the Keycloak extension (using e.g. the default WF properties files). However, once we enable the Keycloak extension, the call to session.invalidate() throws java.lang.IllegalStateException: UT000021: Session already invalidated. What happens is that the Keycloak extension calls session.invalidate() as part of request.logout(), so the second call to session.invalidate() is then invalid. What is weird is that the request.getSession(false) returns what it appears to be a valid (non-invalidated) session.

I am trying to figure the root cause of this issue:

1. Keycloak adapter should not be calling session.invalidate() as part of request.logout()
2. WF/Undertow should not return what it appears to be a valid session when calling request.getSession(false) since the session was already invalided by the Keycloak extension.
3. Something completely different

Please note that the same code works on EAP 6.4.x. The request.getSession(false) returns null and thus the second call to session.invalidate() does not happen.

Thanks for any help. Petr

[pferraro]

Your expectations are correct. HttpServletRequest.getSession(false) should only ever return a valid session, or null.  That said, there is nothing preventing the session from being concurrently invalidated (by a concurrent request), thus there is no way to guarantee that a session reference doesn't become invalid.  I seem to recall that this situation was rectified at some point in the Undertow 1.4.x branch, so you can try manually upgrading undertow to 1.4.10.Final.  If this is still an issue, please file a bug report.

[psiroky]

Thanks pferraro! I've tried with Undertow 1.4.8.Final and the issue is indeed fixed there.