[SHIRO-386] Possibility to use DefaultWebSecurityContext without servlet api

• Type: Wish
• Status: Closed
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: 1.2.0, 1.2.1
• Component/s: Web
• Environment: OSGi
• Assignee: Unassigned
• Reporter: Tuomas Kiviaho
• Created: 17/Sep/12 10:27
• Updated: 09/Feb/15 07:21
• Resolved: 09/Feb/15 07:21

Description

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.