I have several applications deployed, and authenticate these applications via SSO, and everything works flawlessly.
However, when I redeploy an application (without restarting the application server), it causes the logout mechanism to behave incorrectly. The first log out doesn't destroy the session, the second time it finally logs out the user.
I spent some time debugging the code, and from the way it looks to me, this problem originates in undertow/SingleSignOnAuthenticationMechanism.java at master · undertow-io/undertow · GitHub
When the application is first authenticated, the application session manager is saved to a Set (undertow/SingleSignOnAuthenticationMechanism.java at master · undertow-io/undertow · GitHub) and the SessionInvalidationListener is registered to the manager (undertow/SingleSignOnAuthenticationMechanism.java at master · undertow-io/undertow · GitHub). This SessionInvalidationListener then takes care of the session invalidation on log out.
However, when the application is redeployed, all the listeners are removed from the association application session manager, but the application session manager itself is not removed from the Set in SingleSignOnAuthenticationMechanism.
Now when the application has been redeployed and the authentication is done again, the SessionInvalidationListener is not registered this time, because the Set still contains the application session manager.
This causes the logout to not invalidate the session properly on the first try.
It succeeds on the second try, because a session attribute is removed on the first try (undertow/CachedAuthenticatedSessionHandler.java at master · undertow-io/undertow · GitHub), which causes to trigger the session invalidation via notification.
Is this intended behaviour, or a bug? Or am I misunderstanding something?
