Hello Lez,
Thank you for your reply. I have taken your advice an done the following:
1. I have placed the following code in a class that gets initialized when
the application starts up:
private static DefaultSecurityManager mSecurityManager = new
DefaultSecurityManager();
mSecurityManager.setAuthenticator(new MockAuthenticator());
SecurityUtils.setSecurityManager(mSecurityManager);
2. My new setAuthorizerSubject() method is below. (It only gets executed
when the user logs in, it does not get executed every time we call
isPermitted() on the subject object.):
protected void setAuthorizerSubject(UsersDVO user){
DefaultSecurityManager securityManager = (DefaultSecurityManager)
SecurityUtils.getSecurityManager();
securityManager.setRealm(realm);
SecurityUtils.setSecurityManager(securityManager ); //This line is
probably not needed?
Subject currentUser = new
Subject.Builder(securityManager).buildSubject();
if(!currentUser.isAuthenticated()){
UsernamePasswordToken token = new
UsernamePasswordToken(user.getUserName(), "");
try{
currentUser.login(token);
} catch (AuthenticationException ex){
Log.exception(ex);
}
}
this.subject = currentUser;
}
Now I have a new problem. It seems that I am seeing different behavior now
that I am only using one security manager. My permissions are not being
retrieved correctly. After further inspection, it appears that my
doGetAuthorizationInfo() method in my AuthorizingRealm is not being called
when checking permissions. This was being called when I created a new
security manager. As you can see above I am setting the realm in the
security manager above via securityManager.setRealm(realm). Any ideas?
Les Hazlewood-2 wrote
> P.S. Also, if you authenticate a Subject every time you use it (e.g.
> like in REST calls, where you may authenticate every REST request),
> you don't need sessions, since Subject state is re-created on every
> authentication. You can turn off sessions entirely.
>
> This is all covered in the documentation:
> http://shiro.apache.org/session-management.html#SessionManagement-SessionsandSubjectState
>
> HTH,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
> On Wed, May 15, 2013 at 9:38 AM, Les Hazlewood <
> lhazlewood@
> > wrote:
>> Shiro does not create threads for permission checks. What you're
>> seeing is a side-effect of non-standard Shiro usage.
>>
>> It is expected that you (or a config mechanism like shiro.ini or
>> Spring or Guice, etc) create one and only one SecurityManager instance
>> for your entire application. Additionally, DelegatingSubject is an
>> internal implementation class in Shiro - it shouldn't be used directly
>> by application code (it only might ever be used by non-Shiro
>> developers if they are writing framework-integration code for Shiro -
>> not for standard app use cases). If you need to create ad-hoc Subject
>> instances, you should use the Subject.Builder to create ad-hoc Subject
>> instances, passing in the SecurityManager as a constructor argument.
>>
>> In any event, here is what you are seeing:
>>
>> 1. Shiro's default SecurityManager implementation has an internal
>> SessionManager.
>> 2. This SessionManager, if sessions are used, will create a session
>> validation thread (to ensure that orphaned sessions can be cleaned
>> properly).
>> 3. If you authenticate a user, Shiro's default storage mechanism for
>> authenticate state is the session. Because of #2, this will start a
>> session validation thread.
>>
>> So by #2 and #3, if you create a SecurityManager for every
>> authentication, therefore, you'll create a session validation thread
>> for each authentication! (Thanks to Tamás for the hint). So again,
>> permission checks don't create threads at all - what you're seeing is
>> an unrelated issue due to creating a new SecurityManager every time.
>>
>> Here's what I'd do in your scenario:
>>
>> - Create one and only one SecurityManager. Set it on
>> SecurityUtils.setSecurityManager if you have to to ensure it is
>> re-used (although this is not recommended - you would ideally use
>> something like dependency injection or a configuration mechanism of
>> your choice that manages application singletons without using static
>> memory).
>>
>> - Don't create DelegatingSubject instances. Use the Subject.Builder
>> if you have to create ad-hoc Subject instances.
>>
>> For example, (very similar to Christian's example):
>>
>> Subject subject = new
>> Subject.Builder(SecurityUtils.getSecurityManager()).buildSubject();
>> subject.login(usernamePasswordToken);
>> if (subject.isPermitted(whatever)) {
>> do something
>> }
>>
>> Because you built the subject manually (and didn't use
>> SecurityUtils.getSubject()), the built subject is _not_ bound to the
>> current thread, so other calls to SecurityUtils.getSubject() will not
>> return the same Subject. If you manually create Subject instances in
>> Shiro, you are responsible for ensuring thread association if you wish
>> to use SecurityUtils.getSubject() in other parts of your code.
>>
>> HTH,
>>
>> --
>> Les Hazlewood | @lhazlewood
>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>>
>>
>> On Wed, May 15, 2013 at 7:47 AM, Tamás Cservenák <
> tamas@
> > wrote:
>>> Session validating thread....?
>>>
>>> but by looking at the code, um, very strange use of Shiro.. :)
>>>
>>>
>>> On Wed, May 15, 2013 at 4:14 PM, ApacheNinja <
> dpryce7@
> > wrote:
>>>>
>>>> Hello,
>>>>
>>>> Yes, we are using the latest release of Shiro. We are primarily using
>>>> Shiro to check user permissions. We are not using it to log in to our
>>>> application. We are creating our Subject using the following method:
>>>>
>>>> protected void setAuthorizerSubject(UsersDVO user){
>>>> DefaultSecurityManager securityManager = new
>>>> DefaultSecurityManager();
>>>> securityManager.setRealm(realm);
>>>> securityManager.setAuthenticator(new MockAuthenticator());
>>>> SecurityUtils.setSecurityManager(securityManager );
>>>> Subject currentUser = new DelegatingSubject(securityManager);
>>>> if(!currentUser.isAuthenticated()){
>>>> UsernamePasswordToken token = new
>>>> UsernamePasswordToken(user.getUserName(), "");
>>>> try{
>>>> currentUser.login(token);
>>>> } catch (AuthenticationException ex){
>>>> Log.exception(ex);
>>>> }
>>>> }
>>>> this.subject = currentUser;
>>>> }
>>>>
>>>> This is created once when the user logs in. In our application it is
>>>> possible to log in as a general administrator first, then log in again
>>>> as
>>>> a
>>>> more specific user. So this may be called twice. We then use the
>>>> Subject
>>>> object to call the isPermitted() object, which checks to see if the
>>>> user
>>>> has
>>>> access to different portions of our application. In our Realm object
>>>> we
>>>> have set setAuthorizationCachingEnabled(false) (I don't think this
>>>> makes a
>>>> difference but I thought I would include this information anyway).
>>>> Looking
>>>> at the stack trace when calling isPermitted(), I see that it goes
>>>> through
>>>> the Shiro API and then it then calls our implementation
>>>> doGetAuthorizationInfo() :
>>>>
>>>> @Override
>>>> protected AuthorizationInfo
>>>> doGetAuthorizationInfo(PrincipalCollection
>>>> principalCollection) {
>>>> SimpleAuthorizationInfo info = null;
>>>> if( user != null ) {
>>>> info = new SimpleAuthorizationInfo();
>>>> List
> <Role>
> roles =
>>>> roleManager.getRolesForUser(user.getUserID());
>>>> List
> <EPermission>
> permissions =
>>>> permissionManager.getPermissionsForUser(user.getUserID());
>>>> for(Role role : roles) {
>>>> info.addRole(role.getName());
>>>> }
>>>> for(EPermission permission : permissions){
>>>> info.addStringPermission(permission.getName());
>>>> }
>>>> }
>>>>
>>>> return info;
>>>> }
>>>>
>>>> Somewhere in there a new thread is being generated but I don't know
>>>> where.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/Too-many-threads-created-when-calling-isPermitted-tp7578725p7578734.html
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>>
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Too-many-threads-created-when-calling-isPermitted-tp7578725p7578740.html
Sent from the Shiro User mailing list archive at Nabble.com.
