Shiro
  1. Shiro
  2. SHIRO-266

Login/Logout: Enable pluggable Subject state binding

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0, 1.1.0
    • Fix Version/s: 1.2.0
    • Component/s: Session Management, Subject
    • Labels:
      None

      Description

      After login, a subject's state (principals, authentication state, etc) are bound to the Subject's session. This allows Shiro to reconstruct the Subject instance later on by acquiring a Session (e.g. by id) and reconstructing the Subject based on the Session's state.

      In stateless environments (e.g. some REST-enabled applications), it is not desirable to create a session. There should be a pluggable component that performs state binding and unbinding for subject login and logout, respectively. Stateless applications can choose to configure Shiro with a stateless binder if they don't want sessions to be created.

        Issue Links

          Activity

          Hide
          Brian Demers added a comment -

          It would be nice to have a default component that could detect requests from browsers (state-full) and other state-less clients.

          Anyone know of a library that can detect browsers based on user-agent? ( other then us writing and maintaining a table )

          If we had to maintain a table, the problem is updating it with the minor browsers ( KDE konqurer? ). The big ones are easy, WebKit, Mozilla / Gecko, MSIE, Opera.

          Thoughts ?

          Show
          Brian Demers added a comment - It would be nice to have a default component that could detect requests from browsers (state-full) and other state-less clients. Anyone know of a library that can detect browsers based on user-agent? ( other then us writing and maintaining a table ) If we had to maintain a table, the problem is updating it with the minor browsers ( KDE konqurer? ). The big ones are easy, WebKit, Mozilla / Gecko, MSIE, Opera. Thoughts ?
          Hide
          Les Hazlewood added a comment - - edited

          Initial implementation complete. Introduced new concepts (all in the org.apache.shiro.mgt package):

          • SubjectDAO interface and default DefaultSubjectDAO implementation.
          • The DefaultSubjectDAO implementation uses a SessionStateEvaluator (an interface) that allows control of session usage on a per-subject basis.
          • The DefaultSessionStateEvaluator allows session control for all Subjects at a global level.

          Custom per-Subject logic may be performed by end users implementing the SessionStateEvaluator interface and configuring it on the DefaultSubjectDAO. No subclassing of an existing Shiro implementation required.

          • The DefaultSubjectDAO implementation uses efficient 'merge' logic for persisting data to the session - a session is only ever updated if there is a difference in subject state.

          Finally, unit tests were added for all new implementations. 100% method coverage and 100% line coverage.

          Show
          Les Hazlewood added a comment - - edited Initial implementation complete. Introduced new concepts (all in the org.apache.shiro.mgt package): SubjectDAO interface and default DefaultSubjectDAO implementation. The DefaultSubjectDAO implementation uses a SessionStateEvaluator (an interface) that allows control of session usage on a per-subject basis. The DefaultSessionStateEvaluator allows session control for all Subjects at a global level. Custom per-Subject logic may be performed by end users implementing the SessionStateEvaluator interface and configuring it on the DefaultSubjectDAO. No subclassing of an existing Shiro implementation required. The DefaultSubjectDAO implementation uses efficient 'merge' logic for persisting data to the session - a session is only ever updated if there is a difference in subject state. Finally, unit tests were added for all new implementations. 100% method coverage and 100% line coverage.
          Hide
          Les Hazlewood added a comment -

          Documentation here (may be moved eventually):

          https://cwiki.apache.org/confluence/display/SHIRO/Session+Management

          Show
          Les Hazlewood added a comment - Documentation here (may be moved eventually): https://cwiki.apache.org/confluence/display/SHIRO/Session+Management
          Hide
          Les Hazlewood added a comment - - edited

          Resolving only as an indication that I see no further work on this issue. Feel free to re-open if we feel more work should be done or as a result of mailing list discussion.

          Show
          Les Hazlewood added a comment - - edited Resolving only as an indication that I see no further work on this issue. Feel free to re-open if we feel more work should be done or as a result of mailing list discussion.
          Hide
          Les Hazlewood added a comment -

          Adding web-related support

          Show
          Les Hazlewood added a comment - Adding web-related support
          Hide
          Les Hazlewood added a comment -

          Latest commit has the following changes:

          • The DefaultSessionStorageEvaluator has been changed to allow usage of the Session by default if one already exists. If one does not exist, only then is the isSessionStorageEnabled() class-level property consulted. It didn't make sense to not use the session if the application developer has already created one (by calling subject.getSession() somewhere in their own code).
          • New web-specific objects have been introduced to enable most web applications to receive enabling/disabling benefits simply by request-specific configuration. For example, a new 'NoSessionCreationFilter' has been introduced (in the pool of Default Filters as 'noSession'). This can be used in Shiro's filter chains, for example, in shiro.ini:

          [urls]
          /rest/** = noSession, authcBasic

          The 'noSession' filter triggers logic that will prevent both Shiro and application developers from calling subject.getSession() and subject.getSession(true) for request patterns that should be stateless (no sessions).

          A new DefaultWebSessionStorageEvaluator has been introduced that retains the DefaultSessionStorageEvaluator parent class logic, but will additionally look for a request attribute (set by the 'noSession' filter) to trigger this request-specific subject enable/disable logic. The DefaultWebSecurityManager enables this DefaultWebSessionStorageEvaluator by default.

          Finally, more unit tests have been added. DefaultWebSessionStorageEvaluator has 100% method/line coverage.

          Show
          Les Hazlewood added a comment - Latest commit has the following changes: The DefaultSessionStorageEvaluator has been changed to allow usage of the Session by default if one already exists. If one does not exist, only then is the isSessionStorageEnabled() class-level property consulted. It didn't make sense to not use the session if the application developer has already created one (by calling subject.getSession() somewhere in their own code). New web-specific objects have been introduced to enable most web applications to receive enabling/disabling benefits simply by request-specific configuration. For example, a new 'NoSessionCreationFilter' has been introduced (in the pool of Default Filters as 'noSession'). This can be used in Shiro's filter chains, for example, in shiro.ini: [urls] /rest/** = noSession, authcBasic The 'noSession' filter triggers logic that will prevent both Shiro and application developers from calling subject.getSession() and subject.getSession(true) for request patterns that should be stateless (no sessions). A new DefaultWebSessionStorageEvaluator has been introduced that retains the DefaultSessionStorageEvaluator parent class logic, but will additionally look for a request attribute (set by the 'noSession' filter) to trigger this request-specific subject enable/disable logic. The DefaultWebSecurityManager enables this DefaultWebSessionStorageEvaluator by default. Finally, more unit tests have been added. DefaultWebSessionStorageEvaluator has 100% method/line coverage.
          Hide
          Les Hazlewood added a comment -

          Finally, it should be noted that the 'noSession' filter only prevents new sessions from being created. It allows access to any existing session that might have been created in another part of the application by the application developer.

          Show
          Les Hazlewood added a comment - Finally, it should be noted that the 'noSession' filter only prevents new sessions from being created. It allows access to any existing session that might have been created in another part of the application by the application developer.
          Hide
          Les Hazlewood added a comment - - edited

          Made the following changes today:

          • Ensured that direct calls to the HttpServletRequest will honor 'noSessionCreation' filter settings as well (i.e. httpServletRequest.getSession() or httpServletRequest.getSession(true)).
          • Added noSessionCreation checks to WebUtils, but with big warnings (and prefixing with an underscore) to indicate it is not intended to be used by Shiro end users.
          • Changed NoSessionCreationFilter alias in the DefaultFilter enum to be 'noSessionCreation' instead of 'noSession'. It is more verbose but more accurate - it doesn't disable all session usage, just creating them (i.e. another part of the app may create a session that can still be used).
          • Updated the gmaven plugin and actually enabled it for Maven builds (Groovy-based test cases were not being run from the command line - only in the IDE. Now they run via command line builds as expected).
          Show
          Les Hazlewood added a comment - - edited Made the following changes today: Ensured that direct calls to the HttpServletRequest will honor 'noSessionCreation' filter settings as well (i.e. httpServletRequest.getSession() or httpServletRequest.getSession(true)). Added noSessionCreation checks to WebUtils, but with big warnings (and prefixing with an underscore) to indicate it is not intended to be used by Shiro end users. Changed NoSessionCreationFilter alias in the DefaultFilter enum to be 'noSessionCreation' instead of 'noSession'. It is more verbose but more accurate - it doesn't disable all session usage, just creating them (i.e. another part of the app may create a session that can still be used). Updated the gmaven plugin and actually enabled it for Maven builds (Groovy-based test cases were not being run from the command line - only in the IDE. Now they run via command line builds as expected).
          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:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development