[ 
https://issues.apache.org/jira/browse/SHIRO-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457726#comment-13457726
 ] 

Tuomas Kiviaho commented on SHIRO-386:
--------------------------------------

Duplicate security manager setups require duplicate setups for the 
CacheManager, Realms, Authenticators etc.

OSGi bundles for instance can have javax.servlet.http;resolution:=optional 
which is currently already supported via WebUtils.isHttp() and it seemed 
reasonable to have support for javax.servlet;resolution:=optional which is 
already almost supported via WebUtils.isWeb(). This would render out the need 
for duplicate security managers in favor of DefaultWebSecurityManager's 
fallback capability.
                
> Possibility to use DefaultWebSecurityContext without servlet api 
> -----------------------------------------------------------------
>
>                 Key: SHIRO-386
>                 URL: https://issues.apache.org/jira/browse/SHIRO-386
>             Project: Shiro
>          Issue Type: Wish
>          Components: Web
>    Affects Versions: 1.2.0, 1.2.1
>         Environment: OSGi
>            Reporter: Tuomas Kiviaho
>            Priority: Minor
>
> DefaultWebSecurityManager seems to be almost capable of functioning even if 
> servlet api isn't available DefaultSecurityManager. There are couple things 
> that currently prohibits utilizing this feature.
> 1. DefaultWebSecurityManager is fixed to deliver a WebSubjectContext 
> implementation but ClassUtils.isAvailable("javax.servlet.ServletRequest")  
> could be used to determine if falling back to super implementation would be 
> more appropriate. A pluggable subject context provider/factory would 
> eliminate the need of using classpath determination inside the implementation.
> 2. WebUtils has couple of static field dependencies to servlet api which are 
> trivial to factor out.
> 3. ServletContainerSessionManager is not designed to fall back to super class 
> when req/resp do not meet it's needs while creating a session and it only 
> generates an exception from such an attempt. A simple 
> ClassUtils.isAvailable("javax.servlet.http.HttpSession") could be used to 
> make a decision between it and DefaultWebSessionManager. Alternative approach 
> would be deriving the former from latter and using the fallback pattern 
> mentioned is case 1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to