On Fri, Feb 09, 2001 at 03:53:06PM +0100, Pere Torrodellas wrote:
> Hello,
>
> As far as I can tell after browsing through the code, Turbine is not
> using the timeout attribute in the TurbineUser class: I didn't find any
> calls to user.get/setTimeout() or
> getSession().setMaxInactiveInterval().
You're right - that looks like a hangover from a previous idea that was
never properly implemented.
> Is the session timeout management meant to be left to the application?
> If so, shouldn't the place to store the timeout be also left to the
> particular implementation, instead of assuming that it should be in
> TurbineUser? Or did I miss something?
>
> I guess that a possible approach could be to have a session.timeout
> property, and place the following in the LoginUser action:
>
> data.getSession().setMaxInactiveInterval(TurbineResources.getInt("sessio
> n.timeout")
> * 60);
I like the idea of having a gloval property for the session timeout - I
think this is an app-dependent thing, some apps will want short
timeouts for security reasons, some will be happy with long ones...
I would actually put this line in Turbine.java, and have it only call
setMaxInactiveInterval if the property is actually given in
TR.properties.
Unless anyone objects I'll go ahead and make these additions.
> Or Maybe in a SessionValidator subclass... Is there a favored approach?
LoginUser is the wrong place, because session timeout is an issue even
for non-secure apps.
The trouble with putting it in SessionValidator is it involves
duplicating the code for each variety of SessionValidator - and customer
user-written SessionValidator's won't get the code.
> Thanks,
>
> Pere Torrodellas
Thanks for the spot Pere,
Sean
--
Sean Legassick
[EMAIL PROTECTED]
Je suis un homme: rien d'humain en m'est étranger
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
