Hi Les, Thanks very much for your answer - make complete sense. I think the missing piece of the puzzle (for me) was that the thread context can also hold a SecurityManager (I knew it could hold the Subject).
Cheers, Stuart On Wed, Aug 28, 2013 at 5:07 PM, Les Hazlewood <[email protected]>wrote: > 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 >> > >
