I am using tomcat 6.0.28 (actually the 6.0.28-10ubuntu2 package) as a
standalone web server. I am getting timeout behaviour that sort-of makes
sense, but doesn't agree with the way I read the servlet spec.
I have associated the org.apache.catalina.authenticator.SingleSignOn
Valve with my Engine, within the Host definition. It seems to work fine.
1. conf/web.xml sets <session-timeout> to 30 minutes. (I believe this
will be the default used by webapps that do not explicitly define a
value within their individual web.xml files.)
2. My root welcome page does an html redirect to a small webapp called
static, which has its own web.xml. The redirect is to a page which is
protected by a security contraint which requires a FORM-based login
(this server only has an SSL Connector defined). The static web.xml
defines its session-timeout to be 20 minutes.
3. Once the user has authenticated to the static webapp, the client sees
an html page generated by a jsp which provides a menu based on the roles
defined for the individual user.
4. The menu offers url's to other webapps within the same Host and
Realm, therefore within the control of the SSO Valve.
5. When a user navigates to one of these other webapps, it apparently
works fine. However, this second webapp has a web.xml that sets
session-timeout to be 120 minutes.
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.
7. When I attach a debugger to the source code in my second webapp, I
can stop execution and display context variables:
*** HttpServletRequest.StandardSession.maxInactiveInterval has the value
7200 (i.e. 120 minutes),
which is the time defined in the webapp's own xml.
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 can see some relevant logic within the source code of
SingleSignOn.sessionEvent(SessionEvent), but I don't know which session
instance it will be working with:
// Look up the single session id associated with this session (if any)
Session session = event.getSession();
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.
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?
(puzzled)
Brian Burch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
