Shiro
  1. Shiro
  2. SHIRO-287

Enable web-configured SecurityManager to be statically accessible for non-request threads

    Details

      Description

      For any work done on threads that are not triggered by a request thread, the SecurityManager should be accessible to these threads so the Subject.Builder can be used properly.

      This can be accomplished by setting the configured SecurityManager as a static member variable in SecurityUtils (via SecurityUtils.setSubjectManager). While static memory is not ideal, it is probably good enough for 90% of web applications, and can be a viable solution.

        Issue Links

          Activity

          Hide
          Les Hazlewood added a comment -

          I just committed this change to trunk (AbstractShiroFilter). Static memory remains disabled by default (and must be explicitly enabled via a Filter init-param or JavaBeans property) pending further review/discussion.

          Show
          Les Hazlewood added a comment - I just committed this change to trunk (AbstractShiroFilter). Static memory remains disabled by default (and must be explicitly enabled via a Filter init-param or JavaBeans property) pending further review/discussion.
          Hide
          Les Hazlewood added a comment -

          Implemented in trunk w/ supporting test cases (AbstractShiroFilterTest)

          Show
          Les Hazlewood added a comment - Implemented in trunk w/ supporting test cases (AbstractShiroFilterTest)
          Hide
          Les Hazlewood added a comment -

          This feature should probably be removed now that the WebEnvironment concept has been built. End-users can make the ServletContext statically accessible if they wish and use WebUtils.getWebEnvironment to acquire the SecurityManager in non-request threads.

          This means only a single web app can run in the container however. Continued list discussion is probably necessary to figure out our preferred approach.

          Show
          Les Hazlewood added a comment - This feature should probably be removed now that the WebEnvironment concept has been built. End-users can make the ServletContext statically accessible if they wish and use WebUtils.getWebEnvironment to acquire the SecurityManager in non-request threads. This means only a single web app can run in the container however. Continued list discussion is probably necessary to figure out our preferred approach.
          Hide
          Les Hazlewood added a comment -

          Leaving this feature in for now as it is not critical to be removed for the 1.2.0 release.

          Show
          Les Hazlewood added a comment - Leaving this feature in for now as it is not critical to be removed for the 1.2.0 release.
          Hide
          Les Hazlewood added a comment -

          Closing with the 1.2.0 release.

          Show
          Les Hazlewood added a comment - Closing with the 1.2.0 release.

            People

            • Assignee:
              Les Hazlewood
              Reporter:
              Les Hazlewood
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development