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