[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
8:41 a.m.
[
https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin....
]
Richard Janík edited comment on WFLY-5932 at 2/1/16 2:40 AM:
-------------------------------------------------------------
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.
edit:
After discussion with Stuart, I've realized that the process above is unnecessarily
complicated. Still, sso-fix branch doesn't seem to fix the issue.
was (Author: rjanik):
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)
3015
days inactive
3015
days old
0 comments
1 participants
participants (1)
-
Richard Janík (JIRA)