Uploaded image for project: 'Shiro'
  1. Shiro
  2. SHIRO-386

Possibility to use DefaultWebSecurityContext without servlet api

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Wish
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.2.0, 1.2.1
    • Fix Version/s: None
    • Component/s: Web
    • Labels:
      None
    • Environment:
      OSGi

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              tuomas_kiviaho Tuomas Kiviaho

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment