tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Leditschke" <>
Subject Implementing a custom session manager for reauthentication
Date Tue, 25 Nov 2003 11:35:06 GMT
I am currently involved in a project using tomcat 4.1.29
and forms-based authentication. I would appreciate some feedback
on our approach to one of our requirements and conclusions 
about the design of the existing code.

We have a requirement to implement a reauthentication timeout
separate from the session timeout, i.e. after say 5 minutes a
user must re-enter their credentials in order to continue with
their session, which would have a longer timeout.

We've tried doing this in filters without much success, and 
decided that we needed to extend the container instead. 

Looking at the authenticator code, it appears that the way to force
(re)authentication without loosing the session is to ensure that
the session getPrincipal() routine returns null. So we need to 
somehow set the principal to null on reauthentication timeout.

In order to achieve this, one of two approaches came to mind in
examining the manager and session code. Our goal was to try and
use as much as possible of the existing code and extend cleanly.

1. Develop our own session class that implements this behaviour.

We started by considering a delegating instance of StandardSession
that would perform the reauthentication check as part of getPrincipal().
However, looking at the session managers available, StandardSession is
endemic in the code suggesting that extension of session was not big on the
designers radar, particularly given its use in casts and session object

2. Extend the manager of choice and add our own thread to set the
principal to null on reauthentication timeout.

There's a few hairs on this one

a) The existing managers already implement runnable for session timeout, but
we figure an inner class will probably do the trick for our thread
b) We'll need to implement the lifecycle events to control our thread as
well as the superclass thread
c) The Session setPrincipal() method is not synchronised, so the possibility
exists for race conditions between our thread and other code
d) Managers such as StandardManager have hardcoded strings for string
resources and the thread name, rather than basing these on the protected
"name" member. Although we can change the name in our subclass constructor,
we'd still end up with a thread called "StandardManager..." even though
we're actually using our manager. I'm happy to submit a patch if changing
this situation is considered appropriate.

We're pursuing 2) at the moment, but would like to get the opinions on the
points above from those who know the code base better.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message