shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hale (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SHIRO-457) Login without static VM security manager cause exception in debug
Date Mon, 16 Jun 2014 11:55:01 GMT

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

Mark Hale edited comment on SHIRO-457 at 6/16/14 11:54 AM:
-----------------------------------------------------------

So, I have a similar issue that would be fixed by this. So if createSubject does not explicitly
set the security manager. Then it is left to ensureSecurityManager to fix up the issue. The
problem with this is that ensureSecurityManager uses resolveSecurityManager to check for the
security manger which delegates to a thread local check. If the thread local contains a different
security manager then this will end up being used instead of "this" securitymanager. (Surely
it should be getSecurityManager() instead of resolveSecurityManager()???)

Here is my work-around:
		// work-around for SHIRO-457
		// unbind any thread-local security manager to ensure
		// the SecurityManager passed in to Builder is used
		org.apache.shiro.mgt.SecurityManager threadSecurityManager = ThreadContext.unbindSecurityManager();
		Subject subject = new Subject.Builder(securityManager).buildSubject();
		subject.login(new UsernamePasswordToken(username, password));
		ThreadContext.bind(threadSecurityManager);



was (Author: mjhale):
So, I have a similar issue that would be fixed by this. So if createSubject does not explicitly
set the security manager. Then it is left to ensureSecurityManager to fix up the issue. The
problem with this is that ensureSecurityManager uses resolveSecurityManager to check for the
security manger which delegates to a thread local check. If the thread local contains a different
security manager then this will end up being used instead of "this" securitymanager. (Surely
it should be getSecurityManager() instead of resolveSecurityManager()???)

Here is my work-around:
		// work-around for SHIRO-457
		// unbind any thread-local security manager to ensure Subject uses
		// the SecurityManager passed in to Builder
		org.apache.shiro.mgt.SecurityManager threadSecurityManager = ThreadContext.unbindSecurityManager();
		Subject subject = new Subject.Builder(securityManager).buildSubject();
		ThreadContext.bind(threadSecurityManager);


> 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.2#6252)

Mime
View raw message