[jboss-jira] [JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

[Richard Janík (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154422#comment-13154422 ] 

Richard Janík commented on WFLY-5932:
-------------------------------------

Hi Stuart,

first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately.

Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again.
(I'm detailing the process in case you have something to say about it)

What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems?

tl;dr
I don't think commit 394c7b8 fixes the issue - I'm still seeing it.

> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5932
>                 URL: https://issues.jboss.org/browse/WFLY-5932
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR5
>            Reporter: Richard Janík
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)