shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tuomas Kiviaho (JIRA)" <>
Subject [jira] [Commented] (SHIRO-386) Possibility to use DefaultWebSecurityContext without servlet api
Date Tue, 18 Sep 2012 10:19:08 GMT


Tuomas Kiviaho commented on SHIRO-386:

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

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:
>             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:

View raw message