You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Stuart Broad (JIRA)" <ji...@apache.org> on 2013/11/20 11:45:36 UTC

[jira] [Commented] (SHIRO-457) Login without static VM security manager cause exception in debug

    [ https://issues.apache.org/jira/browse/SHIRO-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13827523#comment-13827523 ] 

Stuart Broad commented on SHIRO-457:
------------------------------------

I have just come across another side issue that I think is related to the above code (which the above fix would also resolve).

SecurityUtils.getSecurityManager()
->
ThreadContext.getSecurityManager()
->
ThreadContext.get(..)
->
ThreadContext$InheritableThreadLocalMap.setInitialValue()

The above calls are causing a ThreadLocal to be created which tomcat is complaining about on shutdown (I am destroying the security manager):

SEVERE: The web application [/xxx] created a ThreadLocal with key of type [org.apache.shiro.util.ThreadContext.InheritableThreadLocalMap] (value [org.apache.shiro.util.ThreadContext$InheritableThreadLocalMap@1afb7ac7]) and a value of type [java.util.HashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

As I mentioned above I am not using a static VM security manager.

I have not created a new jira ticket for this.

I have worked around the issue by calling ThreadContext.remove() after logging in.  Not sure if this will have any unwanted side effects (so far so good though).

> Login without static VM security manager cause exception in debug
> -----------------------------------------------------------------
>
>                 Key: SHIRO-457
>                 URL: https://issues.apache.org/jira/browse/SHIRO-457
>             Project: Shiro
>          Issue Type: Bug
>          Components: Authentication (log-in)
>    Affects Versions: 1.2.2
>         Environment: Mac OS X 10.8.3, Java 1.6.0_51
>            Reporter: Stuart Broad
>            Priority: Minor
>
> I have run into a possible issue with regards to using the Subject login(use,pwd) api when the SecurityUtils SecurityManager has not been set (SecurityUtils.setSecurityManager(secMgr).
>         Subject currentUser = new Subject.Builder(securityManager).buildSubject();
>         UsernamePasswordToken token = new UsernamePasswordToken(userName, password);
>         currentUser.login(token);
> The code above results in an exception (this exception is not the end of the world as later in the code the current default security manager will get set so all should be ok):
> 15:31:01.325 [main] DEBUG o.a.s.s.s.DefaultSubjectContext - No SecurityManager available via SecurityUtils.  Heuristics exhausted.
> org.apache.shiro.UnavailableSecurityManagerException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton.  This is an invalid application configuration.
>  	at org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) ~[shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.subject.support.DefaultSubjectContext.resolveSecurityManager(DefaultSubjectContext.java:106) ~[shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.mgt.DefaultSecurityManager.ensureSecurityManager(DefaultSecurityManager.java:411) [shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:333) [shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183) [shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283) [shiro-core-1.2.1.jar:1.2.1]
>  	at org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256) [shiro-core-1.2.1.jar:1.2.1]
> I think the issue rises from line 1 of the following code in DefaultSecurityManager:
>     protected Subject createSubject(AuthenticationToken token, AuthenticationInfo info, Subject existing) {
>         SubjectContext context = createSubjectContext();  <-- Results in a context with no security manager
>         context.setAuthenticated(true);
>         context.setAuthenticationToken(token);
>         context.setAuthenticationInfo(info);
>         if (existing != null) {
>             context.setSubject(existing);
>         }
>         return createSubject(context); <-- This complains about no security manager
>     }
> Could the DefaultSecurityManager code instead be as follows?
>     protected Subject createSubject(AuthenticationToken token, AuthenticationInfo info, Subject existing) {
>         SubjectContext context = createSubjectContext();
>         context.setAuthenticated(true);
>         context.setAuthenticationToken(token);
>         context.setAuthenticationInfo(info);
>         context.setSecurityManager(this); <-- Set the security manager before the createSubject
>         if (existing != null) {
>             context.setSubject(existing);
>         }
>         return createSubject(context);
>     }
> This exception can be masked but I think it would be better not to raise it in this scenario.



--
This message was sent by Atlassian JIRA
(v6.1#6144)