shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood (JIRA)" <>
Subject [jira] [Commented] (SHIRO-312) DefaultSecurityManager.setSessionManager can get out of sync with DefaultSecurityManager.setSessionMode
Date Fri, 22 Jul 2011 20:04:57 GMT


Les Hazlewood commented on SHIRO-312:

I also added some more Deprecation notices and one log message.  The 'sessionMode' property
was added as a convenience to automagically set the SessionManager based on which session
mechanism one wanted to use.  However, this property has caused more than enough problems
due to configuration out-of-order problems based on when you set the property - not nice.
 It's better to just remove it alltogether, so maybe we can do that in 1.3 or 2.0.

> DefaultSecurityManager.setSessionManager can get out of sync with DefaultSecurityManager.setSessionMode
> -------------------------------------------------------------------------------------------------------
>                 Key: SHIRO-312
>                 URL:
>             Project: Shiro
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 1.2.0
>            Reporter: Jared Bunting
>            Assignee: Les Hazlewood
>         Attachments: SessionManager_SHIRO-312.patch, SessionManager_SHIRO-312_b.patch
> So, I've run into a bit of a pickle with DefaultWebSecurityManager and
> native vs http sessions.
> The DefaultWebSecurityManager exposes two methods, ostensibly for the
> purposes of determining how sessions are managed:
> setSessionManager(SessionManager)
> and
> setSessionMode(String)
> However, it would appear that if I call:
> setSessionManager(new MyCustomSessionManager())
> and then
> setSessionMode("native")
> the SessionManager is overridden. 
> This is a bit of a gotcha, but can be easily avoided by not calling
> setSessionMode.  (calling them in the reverse order seems contrary to
> the nature of setters)  The problem with not calling setSessionMode is
> that it appears to actually matter - if I leave it to it's default
> (http), but set a DefaultWebSessionManager, then things break horribly
> (apparently due to the use of isHttpSessionMode by AbstractShiroFilter
> for redirect rewriting).  Sessions get forgotten, etc.  This also seems
> contrary to the nature of setters. 

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message