On 12/10/11 12:35, Brian Burch wrote:
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.
OK, it now all makes some kind of sense. I've discovered that the
Session associated with the second webapp is never being associated with
the SSO instance created by the first webapp. However, the weird thing
is that the protected resources of the second webapp are made available
to the signed-on user through the correct SSO identity.
The reason is that the web.xml of the second webapp does NOT have a
<login-config> section at all, so an <auth-method> is not explicitly
assigned to it. I had not realised this before, but by default the
NoLoginAuthenticator class is used. The authenticate() method of this
no-op class DOES NOT add the Session instance of the second webapp to
the SSO array it has been "properly associated" with.
In other words, all of my other webapps never get associated with the
existing SSO Session array, so they all get timed-out simultaneously
with the first one... effectively, their individual session timeouts are
ignored.
These non-first webapps do not have a <login-config> because users will
NEVER be able to login to their containers - unauthenticated users will
be redirected to the common "static" login and menu container.
I'll do a bit more research on the logic within the various
Authenticator classes to see whether the NoLoginAuthenticator is
behaving "correctly", because I'm not convinced it is yet.
Worse case: code a <login-config> section for each of my webapps, even
though it will never be used to execute code and will only trigger the
association of the new Session instance and therefore have it "live"
under its own timeout and preserve the SSO instance accordingly.
Best case: either change NoLoginAuthenticator or write my own variant
that actually makes the SSO-to-Session association that I need.
(words of encouragement or enlightenment will be appreciated!)
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
