[pferraro]

The reason it didn't work has to do with the improper context of the sso object within the callback (which would already have been closed), which precedes the call to manager.removeSingleSignOn(...).

[ametzaga]

Hi all,

I also have the issue of having to call logout twice, in order to be able to logout. After debugging the code for some time, I have seen that in the session listener of SingleSignOnAuthenticationMechanism, in the sessionDestroyed method, the session arrives always without any attributes.

Once the session is invalidated, my custom HttpSessionListener is called, after it, undertow's SessionListenerBridge is called and it deletes all the attributes from the session, and finally SingleSignOnAuthenticationMechanism's listener is called. But at this point there no any attributes in the session, so this code always gives null:

String ssoId = (String) session.getAttribute(SSO_SESSION_ATTRIBUTE);

I have done a test to take the ssoId from the cookie, instead of using session parameters as shown below:

            if(exchange != null && exchange.getRequestCookies() != null) {
                Cookie cookie = exchange.getRequestCookies().get(cookieName);
                if (cookie != null) {
                    String ssoId = cookie.getValue(); //(String) session.getAttribute(SSO_SESSION_ATTRIBUTE);

It seems to be working for me, anyone has this issue?

Thanks for your help

[pferraro]

This is definitely a bug.

[UNDERTOW-291] SingleSignOnAuthenticationMechanism.sessionDestroyed(...) will never find SSO_ID attribute - JBoss Issue …

[pferraro]

I submitted a fix for this here:

[1.0.x] UNDERTOW-291 Iterate over listeners in reverse for sessionDestroyed() so that SessionListenerBridge is triggered…

Essentially, I fixed the order in which Undertow will invoke its session listeners so that the SingleSignOnAuthenticationMechanism's sessionDestroyed(...) listener method gets invoked before the SessionListenerBridge.  This way the session attribute will be intact.

[tmescic]

Hi guys,

I've noticed that the JSESSIONIDSSO cookie is a session cookie - meaning, the browser will destroy it after a

restart. Is there a way to make the cookie persistent? For example, this can be done with the JSESSIONID cookie

by setting the max-age attribute in web.xml.

@Paul

Will this fix [UNDERTOW-269] SSO not destroyed when the last associated session times out. - JBoss Issue Tracker be a

part of Undertow 1.0.x (and WildFly 8.2)? If this was not planned, I could merge the changes and send a pull request if

that's OK...

[ametzaga]

Hi Paul,

Indeed, using the cookie does not work when there is a session timeout, as the exchange is null. So changing the listeners order is the way to go, so we always have the attributes available.

Thanks!

[pferraro]

I had only submitted a PR for master.  If you can cherry-pick this commit into 1.0.x and send a PR that would be great!