Hi Stuart,

SecurityUtils.getSubject() will check the currently executing Thread to see
if it has any Subject state 'bound' to it, using a ThreadLocal.  The
ThreadLocal state (if it exists) would ideally have access to an
application singleton SecurityManager.

SecurityUtils only falls back to a static singleton if there is no
application singleton available on the executing Thread.

Hopefully this will shed some light:

https://github.com/apache/shiro/blob/1.2.x/core/src/main/java/org/apache/shiro/SecurityUtils.java#L53-L60

Additionally, Subject instances represent identity and state.  But _how_
you access a Subject is an orthogonal concern.  Most people appreciate the
thread association because threads are a common way of representing 'the
currently executing Subject'.  You could obtain a Subject in other ways as
well (such as via some state associated with a Socket connect, or via a
request attribute, etc).

Subject instance creation/existence is a separate concern from _how_
Subjects are obtained.  The Thread-based approach is probably the most
convenient.  This might help as well: http://shiro.apache.org/subject.html (the
'Thread Association' section).

HTH,


--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Thu, Aug 22, 2013 at 4:24 AM, Stuart Broad <[email protected]> wrote:

> In the SecurityUtils documentation it mentions that a non-static
> application singleton is preferred over a VM static singleton:
>
>
> http://shiro.apache.org/static/current/apidocs/org/apache/shiro/SecurityUtils.html#setSecurityManager(org.apache.shiro.mgt.SecurityManager)
>
> However all the examples I find talk about using the following method to
> get the subject:
>
> SecurityUtils.getSubject()
>
> I am having trouble putting these two concepts together.
>
> If you are using a non-static application singleton (for the
> SecurityManager) does that not mean you should interact directly with
> SecurityManager (rather than SecurityUtils)?  However the SecurityManager
> does not have methods such as getSubject().  Alternatively, I thought the
> application could get the subject from the thread state but I don't think
> this is correct either.
>
> Does anyone know how a non-static application singleton implementation
> would typically work?
>
> Cheers,
>
> Stuart
>

Reply via email to