[
https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin....
]
Richard Janík updated WFLY-5932:
--------------------------------
Steps to Reproduce:
* Two servers with a distributable deployment capable of calling Session.invalidate()
(FORM auth), clustered single-sign-on, user added
** A1 = 127.0.0.1:8080/deployment
** A2 = 127.0.0.2:8180/deployment
* Access A1, authenticate, access A2 (we still only have a single session - everything
distributable), invalidate session on A2 (e.g. calling
127.0.0.1:8180/deployment?invalidate=true), access A2:
** Expected: we need to authenticate and then receive a new session
** Actual result: we receive a new session but don't need to authenticate
Affects Version/s: 10.0.0.CR5
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: Clustering
Affects Versions: 10.0.0.CR5
Reporter: Richard Janík
Assignee: Paul Ferraro
Priority: Critical
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)