Hi Jeff, 

no. The default new session will be set from web.xml. Turbine does the 
very first time a reset - after the "container" default setting. This 
happens for the first (probably anonymous) session.

But you may be right, that this may happen only once and after this just 
the container default is applied.

The problem arises, if you invalidate a session... CleanUpValve and 
DefaultLoginvalve just remove attributes ..
I suspect, that as DefaultTurbineRunData.getSession() returns 
getRequest().getSession(), always a new session is created, even if it's 
invalidated before and the session might be never considered new again in 
DefaultSessionTimeoutValve. Turbine does assume no session invalidation - 
?
If we want to allow for session invalidation, we should use getSession
(false) in rundata - only this method does not create a session on the 
fly. DefaultSessionTimeoutValveTest seems not cover this case.
But then why not change rundata.getSession, which may then always return 
request.session(false) and add a new method rundata.setSession, which will 
return request.session(true) to be used only carefully ? 

May be there is a better explanation and another way to go? 

Best regards, Georg




Von:    Jeffery Painter <[email protected]>
An:     [email protected]
Datum:  16.09.2019 21:06
Betreff:        Session timeout



Hi turbine devs,

Just trying to clarify if the session.timeout is still honored if set 
with TR.props or if web.xml  is overriding when we define

<session-config><session-timeout>[time in 
minutes]</session-timeout></session-config>

Should we remove this setting from TR.props and just point users to 
update the web.xml setting instead? (should also update the default 
pipeline xml definition)

o.a.t.pipeline.DefaultSessionTimeoutValve processes the value from 
TR.props, and the valve appears in the "turbine-classic-pipeline.xml", 
but I am not sure how to easily detect if web.xml is overriding.

My guess is yes, as my users reported getting kicked off after an 30 
minutes which is the default set in web.xml :-)

I am going to set both to the same value and see if that resolves the 
issue for now.

Thanks!

Jeff







---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to