shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tuomas Kiviaho (JIRA)" <>
Subject [jira] [Closed] (SHIRO-386) Possibility to use DefaultWebSecurityContext without servlet api
Date Mon, 09 Feb 2015 07:22:34 GMT


Tuomas Kiviaho closed SHIRO-386.
    Resolution: Won't Fix

> 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 was sent by Atlassian JIRA

View raw message