[
https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069796#comment-13069796
]
Les Hazlewood commented on SHIRO-312:
-------------------------------------
Sounds good - thanks for the review.
> DefaultSecurityManager.setSessionManager can get out of sync with
> DefaultSecurityManager.setSessionMode
> -------------------------------------------------------------------------------------------------------
>
> Key: SHIRO-312
> URL: https://issues.apache.org/jira/browse/SHIRO-312
> 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: http://www.atlassian.com/software/jira
