session lifetime

[Mike K <mk...@semanticresearch.com>]

What are the lifetimes of the Shiro sessions?
I am wondering if the session gets modified with every user request.
This is of interest as I am looking at using ZooKeeper to manage session
state and this would impact the invalidation/ propagation strategy.

 
-- 
View this message in context: http://shiro-user.582556.n2.nabble.com/session-lifetime-tp5532601p5532601.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: session lifetime

[Les Hazlewood <lh...@apache.org>]

P.S.  All of this is assuming you've configured Shiro to use its
native sessions.  If deploying in a web environment, by default the
servlet container's sessions will be used, at which point you are
limited to what session management mechanisms the container provides
for you.

If you want to override this in a web app to use Shiro's native
sessions instead of the servlet container's, set the
securityManager.sessionMode = native in your INI config (or
equivalent).  If using Shiro outside a web environment (i.e. your
SecurityManager is not a WebSecurityManager instance), native sessions
are enabled by default.

Cheers,

Les

On Tue, Sep 14, 2010 at 5:17 PM, Les Hazlewood <lh...@apache.org> wrote:
> The default session timeout is 30 minutes, as is typical for most
> session environments (e.g. nearly all servlet containers), so we just
> kept that since most people expect it.  But this timeout can be easily
> configured to any millisecond value, or disabled entirely (not really
> advised though, since some other process would need to clean up the
> orphans this setting would cause).  If necessary, you can also control
> the timeout on a per-session basis.
>
> The system-wide timeout can be dynamically changed at runtime and will
> be reflected for all newly created sessions after the new value is
> set.  Existing sessions created before the system-wide timeout change
> are not affected - they retain their original timeout setting and
> their timeout can only be changed by calling setTimeout on each of
> these sessions.  If you require changing all existing sessions via a
> single method call, please open a feature request.
>
> The session does get modified on every user request to update the
> session's last access timestamp.  This is required in order for
> session validation to work correctly to determine when a session times
> out due to inactivity.  In web applications, the Shiro Filter does
> this update automatically via the session.touch() method.  For non web
> environments (e.g. for RMI) something else must call the touch()
> method to ensure the session validation logic functions correctly.
>
> HTH!
>
> Les
>
> On Tue, Sep 14, 2010 at 4:57 PM, Mike K <mk...@semanticresearch.com> wrote:
>>
>> What are the lifetimes of the Shiro sessions?
>> I am wondering if the session gets modified with every user request.
>> This is of interest as I am looking at using ZooKeeper to manage session
>> state and this would impact the invalidation/ propagation strategy.
>>
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/session-lifetime-tp5532601p5532601.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>

Re: session lifetime

[Les Hazlewood <lh...@apache.org>]

The default session timeout is 30 minutes, as is typical for most
session environments (e.g. nearly all servlet containers), so we just
kept that since most people expect it.  But this timeout can be easily
configured to any millisecond value, or disabled entirely (not really
advised though, since some other process would need to clean up the
orphans this setting would cause).  If necessary, you can also control
the timeout on a per-session basis.

The system-wide timeout can be dynamically changed at runtime and will
be reflected for all newly created sessions after the new value is
set.  Existing sessions created before the system-wide timeout change
are not affected - they retain their original timeout setting and
their timeout can only be changed by calling setTimeout on each of
these sessions.  If you require changing all existing sessions via a
single method call, please open a feature request.

The session does get modified on every user request to update the
session's last access timestamp.  This is required in order for
session validation to work correctly to determine when a session times
out due to inactivity.  In web applications, the Shiro Filter does
this update automatically via the session.touch() method.  For non web
environments (e.g. for RMI) something else must call the touch()
method to ensure the session validation logic functions correctly.

HTH!

Les

On Tue, Sep 14, 2010 at 4:57 PM, Mike K <mk...@semanticresearch.com> wrote:
>
> What are the lifetimes of the Shiro sessions?
> I am wondering if the session gets modified with every user request.
> This is of interest as I am looking at using ZooKeeper to manage session
> state and this would impact the invalidation/ propagation strategy.
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/session-lifetime-tp5532601p5532601.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>