You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Jared Bunting (JIRA)" <ji...@apache.org> on 2011/07/20 05:28:57 UTC
[jira] [Created] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
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
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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069702#comment-13069702 ]
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: 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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Jared Bunting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068145#comment-13068145 ]
Jared Bunting commented on SHIRO-312:
-------------------------------------
After discussion on the dev list, I will be adding a new WebSessionManager interface that a web-specific SessionManager can optionally implement, with a method, "isServletContainerSessions". DefaultSecurityManager's isHttpMode will then use this method to return it's value, and will not use the saved sessionMode string.
> 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
>
> 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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Jared Bunting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069722#comment-13069722 ]
Jared Bunting commented on SHIRO-312:
-------------------------------------
Works for me. I had named it "uses" b/c it "is" just doesn't make sense to me, but for the purposes of JavaBeans introspection, that seems reasonable.
As far as the isHttpSessionMode, I agree with that logic...makes more sense - I was just trying to maintain current behavior, where anything other than "native" returned true.
> 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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069701#comment-13069701 ]
Les Hazlewood commented on SHIRO-312:
-------------------------------------
Thanks Jared - this one worked.
I applied the patch with some minor adjustments:
- I moved the WebSessionManager to the org.apache.shiro.web.session.mgt package to be with the other web session management interfaces/components
- I changed the WebSessionManager's method to be isServletContainerSessions() to be JavaBeans compatible (in case any tools introspect the API).
- Minor JavaDoc additions.
Please feel free to review and offer any further suggestions/adjustments.
> 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
[jira] [Closed] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Les Hazlewood closed SHIRO-312.
-------------------------------
Closing with the 1.2.0 release.
> 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
> Fix For: 1.2.0
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069653#comment-13069653 ]
Les Hazlewood commented on SHIRO-312:
-------------------------------------
Hi Jared,
I can't apply the patch - I believe I'm having errors due to recent changes in the ServletContainerSessionManager class. Would you mind updating to the latest trunk and applying a new patch?
My apologies!
> 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
> 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: http://www.atlassian.com/software/jira
[jira] [Updated] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Les Hazlewood updated SHIRO-312:
--------------------------------
Fix Version/s: 1.2.0
> 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
> Fix For: 1.2.0
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Jared Bunting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jared Bunting updated SHIRO-312:
--------------------------------
Attachment: SessionManager_SHIRO-312_b.patch
Sure thing. This is against svn revision 1149681.
> 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
> 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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069709#comment-13069709 ]
Les Hazlewood commented on SHIRO-312:
-------------------------------------
I had to make one final adjustment. I changed the implementation of isHttpSessionMode() to be the following:
SessionManager sessionManager = getSessionManager();
return sessionManager instanceof WebSessionManager && ((WebSessionManager)sessionManager).isServletContainerSessions();
If the end-user configures something that is not a WebSessionManager, we can't assume that Servlet Container sessions are being used. So this method will return 'false' in that case.
> 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
[jira] [Commented] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Assigned] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Les Hazlewood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Les Hazlewood reassigned SHIRO-312:
-----------------------------------
Assignee: Les Hazlewood
> 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
[jira] [Updated] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Jared Bunting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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" method.
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: https://issues.apache.org/jira/browse/SHIRO-312
> 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: http://www.atlassian.com/software/jira
[jira] [Resolved] (SHIRO-312)
DefaultSecurityManager.setSessionManager can get out of sync with
DefaultSecurityManager.setSessionMode
Posted by "Jared Bunting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHIRO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jared Bunting resolved SHIRO-312.
---------------------------------
Resolution: Fixed
> 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