-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/11/2011 12:35 PM, Brian Burch wrote:
OK, I think I understand the distinction you are making, which is
consistent with there being a Session array (rather than a simple
field) in the SingleSignOnEntry class.
I haven't looked at the implementation, but it sounds plausible that a
SingleSignOnEntry object would contain references (or ids) for each of
the sessions that are involved in the SSO "session".
But I am having trouble understanding the life cycle of a Session.
If the browser has navigated away from my "static" webapp
container, into a completely different webapp container, why does
it still have an associated Session?
I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)
When the browser navigates away from a webapp, the webapp usually
doesn't know, because HTTP clients generally don't ping-back pages and
say "I'm leaving, now". That's why session timeouts exist. So, your
client leaves the "static" webapp and 20 minutes later, the session
timeout there kills the session, which takes-down the whole SSO "session".
I can understand how the browser would retain two Sessions if it
held two tabs open, one to each webapp.
This happens regardless of whether the windows are still open or have
been closed.
I guess in my situation (not everyone's), my "static" webapp is the
only thing that knows anything about the state of the browser, so
the Host and/or Valve don't know whether the browser/user will ever
interact with my "static" webapp again and so feel obliged to keep
the Session alive "just in case".
Exactly. I don't believe the SSO Valve pings the various participating
webapps just to keep their sessions alive anytime you hit a webapp
that's part of the SSO "session" (note that I keep saying "session" in
quotes for the SSO "session" because it's not an HttpSession, but
there is something concrete and cohesive about all of the requests
that come from the client that participate in that SSO).
I suppose what I really need is two levels of timeout logic: a)
each individual webapp already has its own session-timeout defined
within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL
Session should be invalidated.
You're right: see below. Evidently, I was wrong about how this stuff
is supposed to work.
b) SSO should only invalidate the "single sign-on" instance/entry
when THE FINAL webapp Session is expired or otherwise invalidated
(and the Session array is empty).
Sorry, that's against the rules:
"
* As soon as the user logs out of one web application (for example, by
invalidating the corresponding session if form based login is used),
the user's sessions in all web applications will be invalidated. Any
subsequent attempt to access a protected resource in any application
will require the user to authenticate himself or herself again.
"
It doesn't specifically say so, but HttpSession timeouts in a single
webapp does not count as "[logging] out of a web application".
Is it possible for my menu.jsp to invalidate its own Session,
without logging the user off, when it knows the browser will be
sending on a one-way trip to another webapp?
If you are using FORM authentication, then session==login. If you kill
the session, the login expires. Also, killing the session would
take-down the SSO "session" without that helpful timeout that gets you
the 20 minutes you already have :)
Do I need to start researching LifeCycleListeners to achieve my
objective, or would that be a pointless approach?
Hmm... authenticator/SingleSignOn.java has this code and comment in
the session event handler:
// Was the session destroyed as the result of a timeout?
// If so, we'll just remove the expired session from the
// SSO. If the session was logged out, we'll log out
// of all session associated with the SSO.
if (((session.getMaxInactiveInterval()> 0)
&& (System.currentTimeMillis() -
session.getThisAccessedTimeInternal()>=
session.getMaxInactiveInterval() * 1000))
||
(Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) {
removeSession(ssoId, session);
} else {
// The session was logged out.
// Deregister this single session id, invalidating
// associated sessions
deregister(ssoId);
}
So, it looks like the Valve should *not* be expiring your SSO when the
"static" webapp's session expires. Can you confirm that you really are
suffering a timeout? Are there other reasons a session could be
invalidated in any one of your webapps? The "static" one seems like
the most likely candidate, but one of the others could be doing it.
Can you enable debug logging for
org.apache.catalina.authenticator.SingleSignOn? It looks like there
should be lots of good logging emitted in there for you to check.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UtBgACgkQ9CaO5/Lv0PAdpgCfRrcLaxBH3Fm/ornW1gfEjPpY
Ay0AoLokcF2Tqm9KWEd+ORNfGMUPUmuw
=kLUP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
