On 11/10/11 16:27, Christopher Schultz wrote:
Thanks very much for your speedy and informative reply, Christopher.
While my question is fresh in your mind, I hope you will not mind too
much if I ask a couple of relevant questions to clarify your answers below.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/11/2011 10:09 AM, Brian Burch wrote:
6. The user tries to refresh the second webapp's page after about
25 minutes, but the GET fails with 403 status and the explanation
"access to resource has been denied". Apparently, the user's
session has been timed out and so he or she is no longer authorised
to access the resource.
This sounds like expected behavior to me: sessions are distinct
between webapps, even when SSO is being used. That means that the
user's session in the "static" webapp will expire 20 minutes after
their last request to "static", regardless of activity in other
webapps. When that session times-out, the requirements of SSO are that
all webapps participating in the SSO session are terminated.
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single%20Sign%20On
These observations suggest the session is being timed out based on
the value for the webapp first encountered by SSO, possibly
associated with the entire SSO Realm, and is not being modified by
the individual webapps within the Realm.
I think the thing you're missing is that it's not a single session,
it's a single sign-on. The sessions themselves are distinct.
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.
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 can understand how the browser would retain two
Sessions if it held two tabs open, one to each webapp. 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".
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.
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).
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? My feeling is "no" because that would
leave the SSO instance without any active Sessions until the new webapp
starts serving the client.
Do I need to start researching LifeCycleListeners to achieve my
objective, or would that be a pointless approach?
Regardless of my open question, **something** has been waiting for
a timer to pop. The timer must have been set to 20 minutes at the
time it was scheduled, and the session has already been timed-out.
I can see that a SingleSignOnEntry cache entry has an array to
carry multiple Session instances. I wonder whether the "wrong"
Session instance (i.e. not the one currently in conversation with
the client) has been used to establish the timer?
I have read the explanation for the
org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
doesn't really make a lot of sense to me and I'm not sure whether
it is relevant to my problem.
I don't believe it's relevant.
Does my description make sense? I'm not sure whether I am looking
at a bug, or simply a case of how it is intended to work. Does
anyone have any helpful suggestions about how to achieve my desired
behaviour?
I think you have two options:
1. Configure your session timeouts differently
2. Have each webapp ping the others periodically, or whenever a
request comes in for a particular session
The difficult part about #1 is that a user could use a webapp for 4
hours and that's an unreasonable timeout for a session. You could wait
for authentication, then increase the timeout, but you still have the
same problem for legitimate users.
#2 requires that you have webapps communicate with each other and
masquerade as the user in question. There may be performance and
security issues that you'll want to sort-out before you decide to do
this kind of thing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYHAACgkQ9CaO5/Lv0PDB6wCfX3pAFtu4Dhvd1I4ObIa7bR6v
s30An1lMjyuEkth0R97atkiyGm1JNALe
=9m7N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
