public abstract class SecurityUtils extends ObjectAccesses the currently accessible
Subjectfor the calling code depending on runtime environment.
Constructors Constructor Description
All Methods Static Methods Concrete Methods Modifier and Type Method Description
getSecurityManager()Returns the SecurityManager accessible to the calling code.
getSubject()Returns the currently accessible
Subjectavailable to the calling code depending on runtime environment.
setSecurityManager(SecurityManager securityManager)Sets a VM (static) singleton SecurityManager, specifically for transparent use in the
public static Subject getSubject()Returns the currently accessible
Subjectavailable to the calling code depending on runtime environment. This method is provided as a way of obtaining a
Subjectwithout having to resort to implementation-specific methods. It also allows the Shiro team to change the underlying implementation of this method in the future depending on requirements/updates without affecting your code that uses it.
- the currently accessible
Subjectaccessible to the calling code.
IllegalStateException- if no
SecurityManagerinstance is available with which to obtain a
Subject, which which is considered an invalid application configuration - a Subject should always be available to the caller.
public static void setSecurityManager(SecurityManager securityManager)Sets a VM (static) singleton SecurityManager, specifically for transparent use in the
getSubject()implementation. This method call exists mainly for framework development support. Application developers should rarely, if ever, need to call this method. The Shiro development team prefers that SecurityManager instances are non-static application singletons and not VM static singletons. Application singletons that do not use static memory require some sort of application configuration framework to maintain the application-wide SecurityManager instance for you (for example, Spring or EJB3 environments) such that the object reference does not need to be static. In these environments, Shiro acquires Subject data based on the currently executing Thread via its own framework integration code, and this is the preferred way to use Shiro. However in some environments, such as a standalone desktop application or Applets that do not use Spring or EJB or similar config frameworks, a VM-singleton might make more sense (although the former is still preferred). In these environments, setting the SecurityManager via this method will automatically enable the
getSubject()call to function with little configuration. For example, in these environments, this will work:
DefaultSecurityManager securityManager = newAnd then anywhere in the application code, the following call will return the application's Subject:
DefaultSecurityManager(); securityManager.setRealms( ... ); //one or more Realms SecurityUtils.setSecurityManager( securityManager );
Subject currentUser = SecurityUtils.getSubject();
securityManager- the securityManager instance to set as a VM static singleton.
public static SecurityManager getSecurityManager() throws UnavailableSecurityManagerExceptionReturns the SecurityManager accessible to the calling code. This implementation favors acquiring a thread-bound
SecurityManagerif it can find one. If one is not available to the executing thread, it will attempt to use the static singleton if available (see the
setSecurityManagermethod for more on the static singleton). If neither the thread-local or static singleton instances are available, this method throws an
UnavailableSecurityManagerExceptionto indicate an error - a SecurityManager should always be accessible to calling code in an application. If it is not, it is likely due to a Shiro configuration problem.
- the SecurityManager accessible to the calling code.
UnavailableSecurityManagerException- if there is no
SecurityManagerinstance available to the calling code, which typically indicates an invalid application configuration.