shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Shiro and Stateless Applications
Date Mon, 27 Jun 2011 00:54:12 GMT
Hi Dev Team (et. al.),

In working to resolve SHIRO-266 [1], I've finished my initial
implementation attempt and committed it as rev. 1139968.  As this is a
significant contribution wrt how Shiro saves Subject state, so please
review if you get a chance - feedback/comments are welcome.

Implementation strategy:

Using sessions as a Subject storage strategy for Shiro's own
implementation needs was spread out in a few places but it has now
been consolidated and abstracted into a new SubjectDAO concept (now a
JavaBeans-compatible property on the DefaultSecurityManager
implementation (get/setSubjectDAO).

The SubjectDAO will save Subject state to that Subject's Session only
if enabled to do so.  This behavior is enabled by default as it is
expected by most applications, but it is of course configurable.  When
Subject state is stored to the session, it is as efficient as it can
be - effectively performing merge logic to ensure the Session is only
updated if a change is detected.

Session storage of Subject state can be enabled or disabled globally
or on a per-Subject basis.

Documentation is here:
and will be sync'd to the main site soon enough.

Unit tests for all new code is at 100% method and line coverage.

In reading the documentation, for those interested in the 'Hybrid'
approach, pay particular attention to the 'Subject Inspection'
section, as you'll find you can get access to more things than just
the Subject itself in a nifty way to help make your enabled/disabled

Feedback is welcome.

Best regards,

Les Hazlewood
CTO, Katasoft | | 888.391.5282
katasoft blog:
personal blog:

View raw message