Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
1.2.1
-
None
Description
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?