You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Stuart Broad <st...@moogsoft.com> on 2013/08/22 13:24:56 UTC
SecurityUtils vs non-static application singleton
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
Re: SecurityUtils vs non-static application singleton
Posted by Les Hazlewood <lh...@apache.org>.
Glad to help!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Wed, Aug 28, 2013 at 9:24 AM, Stuart Broad <st...@moogsoft.com> wrote:
> 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 <lh...@apache.org>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 <st...@moogsoft.com>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
>>>
>>
>>
>
Re: SecurityUtils vs non-static application singleton
Posted by Stuart Broad <st...@moogsoft.com>.
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 <lh...@apache.org>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 <st...@moogsoft.com> 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
>>
>
>
Re: SecurityUtils vs non-static application singleton
Posted by Les Hazlewood <lh...@apache.org>.
This might also help as well:
https://github.com/apache/shiro/blob/1.2.x/core/src/main/java/org/apache/shiro/SecurityUtils.java#L114-L127
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Wed, Aug 28, 2013 at 9:07 AM, Les Hazlewood <lh...@apache.org>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 <st...@moogsoft.com> 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
>>
>
>
Re: SecurityUtils vs non-static application singleton
Posted by Les Hazlewood <lh...@apache.org>.
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 <st...@moogsoft.com> 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
>