[keycloak-user] Logout issue: UT000021: Session already invalidated with EAP7/WF10 adapter

[Petr Široký]

Just to follow up. The root cause of this issue is bug in Undertow, 
which has been fixed for UT 1.4.7.Final.

Workaround is to catch the IllegalStateException coming from the 
session.invalidate().

Petr

On 02/04/2017 05:31 PM, Petr Široký wrote:
> The exception does not come from the Keycloak adapter code (which does
> the first session.invalidate()), but rather from our code which calls
> the session.invalidate() again (after calling the request.logout()). I
> am not saying this is necessarily bug in Keycloak (calling
> session.invalidate() as part of request.logout()) I am just trying to
> figure out where the issue is.
>
>
> On 02/04/2017 12:10 AM, Bill Burke wrote:
>> Log a jira.  We should probably just wrap session.invalidate() to make
>> sure no exception percolates up.
>>
>>
>> On 2/3/17 11:50 AM, Petr Široký wrote:
>>> Hello everyone,
>>>
>>> I am having a logout issue when using the EAP7/WF10 adapter
>>> (2.5.1.Final) with EAP 7.0.0.GA. The server is RH-SSO 7.0.0.GA (but I
>>> also tried the upstream Keycloak 2.5.1.Final).
>>>
>>> This is a simplified version of the code (full reproducer here
>>> https://github.com/psiroky/servlet-app-keycloak-reproducer):
>>>
>>> public void doGet(HttpServletRequest request, HttpServletResponse
>>> response) throws ServletException, IOException {
>>>             ....
>>>             request.logout();
>>>             HttpSession session = request.getSession(false);
>>>             if (session != null) {
>>>                 session.invalidate();
>>>             }
>>>             ...
>>> }
>>>
>>> The code first calls request.logout() and then session.invalidate().
>>> This works OK when we are _not_ using the Keycloak adapter. However,
>>> once we switch to Keycloak adapter we end up with
>>> "java.lang.IllegalStateException:UT000021: Session already invalidated".
>>> I've been debugging the calls and it happens, because the
>>> request.logout() bubbles down to the Keycloak adapter code which calls
>>> session.invalidate() as well. For some reason (bug in Undertow/EAP?) the
>>> request.getSession(false) then returns what it seems to be a valid
>>> session (the invalidated flag=false). The session.invalidate() call
>>> happens again, but the session was in fact already invalidated and thus
>>> Undertow throws that IllegalStateException.
>>>
>>> Please note that exactly the same code works on EAP 6 (+ EAP6 adapter).
>>> The session also gets invalidated as part of logout(), but then the
>>> request.getSession(false) returns null, so the second call to
>>> invalidate() does not happen (this kind of points to Undertow as the
>>> culprit).
>>>
>>> I am trying to figure out what the root cause is:
>>>
>>>      1) Our application should _not_ call both request.logout() and then
>>> session.invalidate() (even though it works for EAP6 and also with e.g.
>>> basic auth without the Keycloak integration)
>>>
>>>      2) Keycloak adapter should not call session.invalidate() as part of
>>> request.logout()
>>>
>>>      3) Undertow does not properly propagate the invalidate() call by the
>>> Keycloak adapter.
>>>
>>>      4) Something completely different?
>>>
>>>
>>> Thanks,
>>> Petr
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user