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 creation. 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. Regards Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
