You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jeffery Painter <je...@jivecast.com> on 2019/09/16 19:06:12 UTC

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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org


Re: Session timeout

Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
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 <je...@jivecast.com>
An:     dev@turbine.apache.org
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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org



Re: Session timeout

Posted by Thomas Vandahl <tv...@apache.org>.
Hi Jeff,

On 16.09.19 21:06, Jeffery Painter wrote:
> 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)

Yes. I believe that the session timeout should be installation-specific
(IOW up to the operator) and not application-specific. I'm +1 for
removing it from Turbine.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org