You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Jochen Munz (JIRA)" <ji...@apache.org> on 2013/03/26 08:39:15 UTC

[jira] [Created] (SHIRO-430) Support for multiple session timeouts

Jochen Munz created SHIRO-430:
---------------------------------

             Summary: Support for multiple session timeouts
                 Key: SHIRO-430
                 URL: https://issues.apache.org/jira/browse/SHIRO-430
             Project: Shiro
          Issue Type: Improvement
          Components: Session Management
    Affects Versions: 1.2.1
            Reporter: Jochen Munz
            Priority: Minor


Quoting from the mailing list (http://grokbase.com/t/shiro/user/128h0pe5xv/support-for-multiple-session-timeouts) as my requirement is exactly the same:

> I'm trying to support an app that has multiple session timeouts depending on
> how the users interact with it. One way is to use a mobile app, and the
> other is a web-based version. Both access the same backend using AJAX, and I
> use Shiro to authenticate those queries and handle the session timeouts.
> Because the mobile app will only be used on locked mobile phones, I would
> like to have the session timeout to be substantially longer than would be
> acceptable for the web version (several hours v. ~15 minutes).



Lez was kind enough to suggest several approaches to this in his post on the mailing list:
* custom servlet filter (not an option for me here)
* add a session listener
* subclassing session manager

In the default configuration the session listener receives only a SimpleSession object - a change to the timeout value is not persisted back to the session store (redis in my case).

So subclassing the session manager currently seems to be the only option, the problem being the call to "applyGlobalSessionTimeout" after the session has been created.


Lez suggested to have sth like a "sessionTimeoutResolver" in an upcoming version, but this might not really be necessary as a custom session factory is capable of doing this. This is also the approach I have been taking before realizing that my changes get overwritten by the the "applyGlobalSessionTimeout" that  overwrites my changes.

The session storage sees this access pattern (with custom factory and listener):
* session factory creates session with custom timeout
* applyGlobal reads session back from store and sets the default timeout
* listener receives simplesession object with default timeout, tries to change but change is persisted


>From my point of view the easiest way would be to apply the global session timeout in the session factory, allowing custom factories to change timeouts as they see fit.

Is this a viable alternative approach, or am I missing something here?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira