[
https://issues.apache.org/jira/browse/SHIRO-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho closed SHIRO-386.
--------------------------------
Resolution: Won't Fix
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
