SecurityUtils

Accesses the currently accessible {@code Subject} for the calling code depending on runtime environment.

Members

Static functions

getSecurityManager
SecurityManager getSecurityManager(string name)

Returns the SecurityManager accessible to the calling code. <p/> This implementation favors acquiring a thread-bound {@code SecurityManager} if 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 {@link #setSecurityManager setSecurityManager} method for more on the static singleton). <p/> If neither the thread-local or static singleton instances are available, this method {@code UnavailableSecurityManagerException} to 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.

getSubject
Subject getSubject(string managerName)

Returns the currently accessible {@code Subject} available to the calling code depending on runtime environment. <p/> This method is provided as a way of obtaining a {@code Subject} without 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.

newSubject
Subject newSubject(string managerName, string sessionId, string host)
Undocumented in source. Be warned that the author may not have intended to support it.
setSecurityManager
void setSecurityManager(string name, SecurityManager securityManager)

Sets a VM (static) singleton SecurityManager, specifically for transparent use in the {@link #getSubject() getSubject()} implementation. <p/> <b>This method call exists mainly for framework development support. Application developers should rarely, if ever, need to call this method.</b> <p/> The Shiro development team prefers that SecurityManager instances are non-static application singletons and <em>not</em> 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. <p/> 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. <p/> 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 {@link #getSubject() getSubject()} call to function with little configuration. <p/> For example, in these environments, this will work: <pre> DefaultSecurityManager securityManager = new {@link hunt.shiro.mgt.DefaultSecurityManager DefaultSecurityManager}(); securityManager.setRealms( ... ); //one or more Realms <b>SecurityUtils.setSecurityManager( securityManager );</b></pre> <p/> And then anywhere in the application code, the following call will return the application's Subject: <pre> Subject currentUser = SecurityUtils.getSubject();</pre>

Meta