2011/10/12 Brian Burch <br...@pingtoo.com>: > > I've successfully run a remote debugger session against the SingleSignOn > Valve while it is handling my timeout scenario. > > Interestingly, the logic to handle the timeout of a single webapp is exactly > as I wanted it to be... only the specific Session is removed from the array > and the SSOEvent remains cached and valid until the array becomes empty. > However, when the first of the two Sessions times out, the array immediately > becomes empty and so the SSOEntry is legitimately deregistered! > > It seems the second, longer-lived, webapp's Session is no longer associated > with the existing SSOEntry when the first webapp times out. I noticed the > second Session being validated, but didn't follow that particular bit of > logic. I will run the scenario again to see what happens when the second > webapp is first called. >
Something becomes clearer. Remembering the session as associated with ssoid is performed by SingleSignOn.associate(..) method. This method is called by AuthenticatorBase class. Those webapps with long living sessions - are they protected by security constraints in their web.xml? (If they are not, then authentication does not happen and their sessions are not associated with SSO)/ Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
