shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jared Bunting (JIRA)" <>
Subject [jira] [Updated] (SHIRO-312) DefaultSecurityManager.setSessionManager can get out of sync with DefaultSecurityManager.setSessionMode
Date Wed, 20 Jul 2011 03:48:57 GMT


Jared Bunting updated SHIRO-312:

    Attachment: SessionManager_SHIRO-312.patch

Adds the WebSessionManager interface with a usesServletContainerSessions method.  This interfaces
is not required to be implemented, and if the SessionManager does not implement it, the behavior
is the same as previously when the sessionMode was null.

I have not deprecated the setSessionMode convenience method, but I have deprecated use of
that field in an attempt to avoid it being used for any logic outside of the "setSessionMode"

I have also added a test case to ensure that isHttpSessionMode is actually using the return
value of the WebSessionManager's method.

> 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
>         Attachments: SessionManager_SHIRO-312.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