Shulou(Shulou.com)06/02 Report--

How to carry out Shiro analysis, in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1.Shiro basic architecture

What is Shiro

Apache Shiro is a powerful and easy-to-use Java security framework that provides authentication, authorization, encryption, and session management functions:

Authentication-user identification, often referred to as user "login"; authorization-access control; password encryption-protects or hides data from snooping; session management-time-sensitive state associated with each user.

For any application, Shiro can provide comprehensive security management services. And Shiro is much simpler than other security frameworks.

II. Introduction to the architecture of Shiro

First, let's take a look at the three core components of Shiro: Subject, SecurityManager and Realms. As shown below:

Subject: "current operation user". However, in Shiro, the concept of Subject does not refer only to people, but also to third-party processes, back-end accounts (Daemon Account), or other similar things. It just means "what currently interacts with the software". But for most purposes and uses, you can think of it as Shiro's "user" concept.

Subject represents the security operations of current users, while SecurityManager manages the security operations of all users.

SecurityManager: it is the core of the Shiro framework, a typical Facade pattern, Shiro manages internal component instances through SecurityManager, and provides various security management services through it.

Realm: Realm acts as a "bridge" or "connector" between Shiro and application security data. That is, when authentication (login) and authorization (access control) authentication are performed on a user, Shiro looks up the user and their permission information from the Realm configured by the application.

In this sense, Realm is essentially a security-related DAO: it encapsulates the connection details of the data source and provides the relevant data to the Shiro when needed. When configuring Shiro, you must specify at least one Realm for authentication and / or authorization. It is possible to configure multiple Realm, but at least one is required.

Shiro has built-in Realm that can connect to a large number of secure data sources (aka directories), such as LDAP, relational database (JDBC), INI-like text configuration resources, and property files. If the default Realm does not meet the requirements, you can also insert your own Realm implementation that represents a custom data source.

Complete architecture diagram of Shiro:

In addition to the three core components of Subject, SecurityManager and Realm mentioned above, the main components of Shiro include:

Authenticator: authentication is the process of verifying a user's identity. A common example of this process is the familiar "user / password" combination. When most users log in to the software system, they usually provide their own user name (party) and password (certificate) that supports them. If the password (or password representation) stored in the system matches the one provided by the user, they are considered authenticated.

Authorizer: authorization is essentially access control-controlling what content in the application users can access, such as resources, Web pages, and so on.

SessionManager: in the area of security frameworks, Apache Shiro provides something unique: Session API can be used consistently at any application or architectural layer. That is, Shiro provides a session programming paradigm for any application-from small background stand-alone applications to large cluster Web applications. This means that application developers who want to use sessions are not forced to use Servlet or EJB containers. Or, if you are using these containers, developers can now choose to use a consistent session API at any layer instead of the Servlet or EJB mechanism.

CacheManager: provides caching support for other components of Shiro.

Authentication Mechanism of 2.Shiro

Authentication is the process of verifying a user's identity. In the authentication process, the user needs to submit entity information (Principals) and credential information (Credentials) to verify whether the user is legal. The most common entity / credential combination is the username / password combination.

I. Shiro authentication process

1. Collect entity / credential information

Java code

/ / Example using most common scenario of username/password pair:

UsernamePasswordToken token = new UsernamePasswordToken (username, password)

/ / "Remember Me" built-in:

Token.setRememberMe (true)

UsernamePasswordToken supports the most common user name / password authentication mechanism. At the same time, because it implements the RememberMeAuthenticationToken interface, we can set the "remember me" function through tokens.

However, there is a difference between "remembered" and "certified":

Remembered users are only non-anonymous users, and you can get user information through subject.getPrincipals (). But it is not a fully authenticated user, and you still need to resubmit authentication information when you access functions that require authentication.

This distinction can be referred to Amazon, which remembers the logged-in users by default. When you visit the site again, the page will display remembered user information for non-sensitive page functions, but you still need to log in again when you access the site's account information.

2. Submit entity / credential information

Java code

Subject currentUser = SecurityUtils.getSubject ()

CurrentUser.login (token)

After collecting the entity / credential information, we can get the current user through the SecurityUtils utility class, and then submit the authentication by calling the login method.

3. Authentication processing

Java code

Try {

CurrentUser.login (token)

} catch (UnknownAccountException uae) {...

} catch (IncorrectCredentialsException ice) {...

} catch (LockedAccountException lae) {...

} catch (ExcessiveAttemptsException eae) {...

}... Catch your own...

} catch (AuthenticationException ae) {

/ / unexpected error?

}

If the login method finishes execution and no exception information is thrown, the user is considered authenticated. Then call SecurityUtils.getSubject () anywhere in the application to get the current authenticated user instance, and use subject.isAuthenticated () to determine whether the user has been authenticated or not will return true.

Conversely, if an exception is thrown during the execution of the login method, authentication is considered to have failed. Shiro has a rich set of hierarchical exception classes to describe the causes of authentication failures, such as code examples.

2. Logout operation

The login operation can delete your login information by calling subject.logout (), such as:

Java code

CurrentUser.logout (); / / removes all identifying information and invalidates their session too.

When the logout operation is completed, the Session information will be cleared and the subject will be treated as an anonymous user.

III. Internal processing mechanism of certification

The above is the process of Shiro authentication in the application. The internal processing mechanism of Shiro authentication will be explained in detail below.

As shown in the figure above, we use the authentication section of the Shiro architecture diagram to illustrate the internal processing sequence of Shiro authentication:

1. After the application has constructed an AuthenticationToken instance of the end-user authentication information, call the Subject.login method.

2. The instance of Sbuject is usually an instance object of the DelegatingSubject class (or subclass). At the beginning of authentication, the securityManager instance set by the application will be entrusted to call the securityManager.login (token) method.

3. After receiving the token (token) information, SecurityManager will delegate an instance of the built-in Authenticator (usually an instance of the ModularRealmAuthenticator class) to call authenticator.authenticate (token). ModularRealmAuthenticator adapts one or more Realm instances set during the authentication process, which actually provides a pluggable authentication mechanism for Shiro.

4. If more than one Realm,ModularRealmAuthenticator is configured in the application, the multi-Realm authentication process will be carried out according to the configured AuthenticationStrategy (authentication policy). After Realm is called, AuthenticationStrategy responds to the results of each Realm.

Note: if only one Realm,Realm is configured in the application, it will be called directly without the need to configure the authentication policy.

5. Determine whether each Realm supports the submitted token. If so, Realm will call getAuthenticationInfo (token). The getAuthenticationInfo method is the actual authentication process. We write our custom authentication processing by overriding the doGetAuthenticationInfo method of Realm.

Fourth, the processing mechanism of using multiple Realm:

1 、 Authenticator

The default implementation is ModularRealmAuthenticator, which supports both a single Realm and multiple Realm. If only one Realm,ModularRealmAuthenticator is configured, the Realm will be directly called to process the authentication information. If more than one Realm is configured, it will adapt the Realm according to the authentication policy and find the appropriate Realm to execute the authentication information.

Customize the configuration of Authenticator:

Java code

[main]

...

Authenticator = com.foo.bar.CustomAuthenticator

SecurityManager.authenticator = $authenticator

2. AuthenticationStrategy (authentication policy)

When the application is configured with multiple Realm, the ModularRealmAuthenticator will judge whether the authentication is successful or failed according to the authentication policy.

For example, if only one Realm verification succeeds and the other Realm verification fails, is the authentication successful this time? If most of the Realm verification is successful, is the authentication considered successful? Or, after a Realm verification is successful, do you need to judge the results of other Realm? The authentication strategy is to make decisions on these issues according to the needs of the application.

The authentication policy is a stateless component that is called 4 times during the authentication process:

Before all Realm is called, before calling the getAuthenticationInfo method of Realm, after calling the getAuthenticationInfo method of Realm, after all Realm is called

Another task of the authentication policy is to aggregate the result information of all Realm into an AuthenticationInfo instance and return this information as the identity information of Subject.

Shiro has three specific implementations of authentication policies:

AtLeastOneSuccessfulStrategy

As long as one (or more) Realm verification is successful, the authentication will be considered a success

FirstSuccessfulStrategy

If the first Realm verification is successful, the overall authentication will be considered successful, and the subsequent Realm will be ignored.

AllSuccessfulStrategy

Authentication is considered successful only if all Realm are successful.

The default implementation of ModularRealmAuthenticator's built-in authentication policy is AtLeastOneSuccessfulStrategy, which is also a widely used authentication policy. Of course, you can also define the policies you need through configuration files, such as:

Java code

[main]

...

AuthcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy

SecurityManager.authenticator.authenticationStrategy = $authcStrategy

...

3. The order of Realm

From the authentication strategy just mentioned, we can see that the order of Realm in ModularRealmAuthenticator has an impact on authentication.

ModularRealmAuthenticator reads the Realm configured in SecurityManager. When authentication is performed, it iterates through the Realm collection and calls getAuthenticationInfo on all Realm that support the submitted token.

Therefore, if the order of Realm affects the result of the authentication policy you use, then you should clearly define the order of Realm in the configuration file, such as:

Java code

BlahRealm = com.company.blah.Realm

...

FooRealm = com.company.foo.Realm

...

BarRealm = com.company.another.Realm

SecurityManager.realms = $fooRealm, $barRealm, $blahRealm

Authorization Mechanism of 3.Shiro

Authorization is access control, which determines whether the user has the appropriate access to the resource in the application.

For example, determine whether a user has the right to view the page, to edit data, to have a button, to print, and so on.

I. the three elements of authorization

Authorization has three core elements: permissions, roles, and users.

Authority

Permissions are the core element of Apache Shiro security mechanism. It explicitly states the allowed behavior and performance in the application. A well-formed permission statement can clearly express the permissions the user has on the resource.

Most resources support typical CRUD operations (create,read,update,delete), but any operation based on a particular resource makes sense. Therefore, the fundamental idea of permission declaration is based on resources and operations.

We can only know what the permission can do in the application through the permission declaration, but we can't determine who has the permission.

Therefore, we need to associate users and permissions in the application.

The usual practice is to assign permissions to a role and then associate that role with one or more users.

Permission declaration and granularity

Shiro permission declarations are usually made using expressions separated by colons. As mentioned earlier, a permission expression can clearly specify the resource type, allowed operations, and accessible data. At the same time, Shiro permission expressions support simple wildcards, which can be more flexible in setting permissions.

Here is an example to illustrate the permission expression.

User data can be queried

User:view

User data can be queried or edited

User:view,edit

All operations can be performed on user data

User:* or user

Editable user data with an id of 123

User:edit:123

Role

Shiro supports two role modes:

1. Traditional role: a role represents a series of operations. when an operation needs to be authorized and verified, it is only necessary to determine whether it is the role or not. The permissions of this role are relatively simple and vague, and are not conducive to expansion.

2. Permission role: a role has a collection of permissions. When you verify authorization, you need to determine whether the current role has that permission. This role permission can give a detailed description of the role, which is suitable for more complex permission design.

The authorization implementation of the two role modes is described in detail below.

II. Implementation of authorization

Shiro supports three ways to implement the authorization process:

Coding implementation annotations to implement JSP Taglig implementation

1. Implementation of authorization based on coding

1.1 implementation based on traditional role authorization

When you need to verify that the user has a role, you can call the hasRole* method of the Subject instance to verify.

Java code

Subject currentUser = SecurityUtils.getSubject ()

If (currentUser.hasRole ("administrator")) {

/ / show the admin button

} else {

/ / don't show the button? Grey it out?

}

The relevant verification methods are as follows:

Subject method

Description

HasRole (String roleName)

Returns true when the user has the specified role

HasRoles (List roleNames)

Returns a corresponding array of Boolean values in list order

HasAllRoles (Collection roleNames)

Return true if the user has all the specified roles

Assertion support

Shiro also supports authorization verification in the form of assertions. The assertion succeeds, no value is returned, and the program continues to execute; when the assertion fails, an exception is thrown. Using assertions can make our code more concise.

Java code

Subject currentUser = SecurityUtils.getSubject ()

/ / guarantee that the current user is a bank teller and

/ / therefore allowed to open the account:

CurrentUser.checkRole ("bankTeller")

OpenBankAccount ()

Related methods of assertions:

Subject method

Description

CheckRole (String roleName)

Assert whether the user has the specified role

CheckRoles (Collection roleNames)

Assert whether the user has all specified roles

CheckRoles (String... RoleNames)

Overload the method of the previous method

1.2 implementation of authorization based on permission role

Compared with the traditional role model, the role model based on permissions is less coupled, and it will not modify the source code due to the change of roles. Therefore, the role model based on permissions is a better way of access control.

Its code implementation can be implemented in the following ways:

1. Implementation based on permission object

Create an instance of org.apache.shiro.authz.Permission and pass the instance object as a parameter to Subject.isPermitted () for validation.

Java code

Permission printPermission = new PrinterPermission ("laserjet4400n", "print")

Subject currentUser = SecurityUtils.getSubject ()

If (currentUser.isPermitted (printPermission)) {

/ / show the Print button

} else {

/ / don't show the button? Grey it out?

}

Permission printPermission = new PrinterPermission ("laserjet4400n", "print")

Subject currentUser = SecurityUtils.getSubject ()

If (currentUser.isPermitted (printPermission)) {

/ / show the Print button

} else {

/ / don't show the button? Grey it out?

}

The related methods are as follows:

Subject method

Description

IsPermitted (Permission p)

Returns treu when Subject has the permission to make it.

IsPermitted (List perms)

Returns the boolean array of the corresponding permissions

IsPermittedAll (Collection perms)

Return true when Subject has all set permissions

2. Implementation based on string

Compared with the clunky object-based implementation, the string-based implementation is more concise.

Java code

Subject currentUser = SecurityUtils.getSubject ()

If (currentUser.isPermitted ("printer:print:laserjet4400n")) {

/ / show the Print button

} else {

/ / don't show the button? Grey it out?

}

Permission expressions separated by colons are the default implementation supported by org.apache.shiro.authz.permission.WildcardPermission.

This represents the resource type: operation: resource ID

Similar to object-based implementation related methods, string-based implementation related methods:

IsPermitted (String perm), isPermitted (String...) Perms), isPermittedAll (String... Perms)

Implementation of assertion based on permission object

Java code

Subject currentUser = SecurityUtils.getSubject ()

/ / guarantee that the current user is permitted

/ / to open a bank account:

Permission p = new AccountPermission ("open")

CurrentUser.checkPermission (p)

OpenBankAccount ()

Implementation of assertion based on string

Java code

Subject currentUser = SecurityUtils.getSubject ()

/ / guarantee that the current user is permitted

/ / to open a bank account:

CurrentUser.checkPermission ("account:open")

OpenBankAccount ()

Related methods for the implementation of assertions

Subject method

Description

CheckPermission (Permission p)

Assert whether the user has the right to make

CheckPermission (String perm)

Assert whether the user has the right to make

CheckPermissions (Collection perms)

Asserts whether the user has all the specified permissions

CheckPermissions (String... Perms)

Asserts whether the user has all the specified permissions

2. Implementation of authorization based on annotations

Shiro annotations support AspectJ, Spring, Google-Guice, etc., and can be configured differently according to the application.

Related notes:

@ RequiresAuthentication

User classes / attributes / methods can be used to indicate that the current user needs to be an authenticated user.

Java code

@ RequiresAuthentication

Public void updateAccount (Account userAccount) {

/ / this method will only be invoked by a

/ / Subject that is guaranteed authenticated

...

}

@ RequiresGuest

Indicates that the user needs to be a "guest" user

@ RequiresPermissions

The current user needs to have the right to make a decision.

Java code

@ RequiresPermissions ("account:create")

Public void createAccount (Account account) {

/ / this method will only be invoked by a Subject

/ / that is permitted to create an account

...

}

@ RequiresRoles

The current user needs to have a defined role

@ RequiresUser

The current user needs to be an authenticated or remembered user

3. Authorization implementation based on JSP TAG

Shiro provides a set of JSP tag libraries to implement page-level authorization control.

Before using the Shiro tag library, you first need to introduce the shiro tag in JSP:

Java code

Here are the tags for Shiro one by one:

Guest tag

Verify whether the current user is a "guest", that is, an unauthenticated (including unremembered) user

Xml code

Hi there! Please Login or Signup today!

User tag

Users who have been authenticated or remembered

Xml code

Welcome back John! Not John? Click here to login.

Authenticated tag

Authenticated users. Does not include remembered users, which is different from the user tag.

Xml code

Update your contact information.

NotAuthenticated tag

Unauthenticated user, corresponding to the authenticated tag. Unlike the guest tag, the tag contains remembered users.

Xml code

Please login in order to update your credit card information.

Principal tag

Output current user information, usually login account information

Xml code

Hello, how are you today?

HasRole tag

Verify whether the current user belongs to this role

Xml code

Administer the system

LacksRole tag

Contrary to hasRole tag logic, authentication passes when the user does not belong to the role

Xml code

Sorry, you are not allowed to administer the system.

HasAnyRole tag

Verify that the current user belongs to any of the following roles.

Xml code

You are either a developer, project manager, or administrator.

HasPermission tag

Verify whether the current user has the right to make

Xml code

Create a new User

LacksPermission tag

Contrary to the hasPermission tag logic, when the current user does not have established permissions, the verification is passed

Xml code

Create a new User

III. The internal processing mechanism of Shiro authorization

1. Call the authorization verification method in the application (isPermitted* or hasRole* of Subject, etc.)

2. The instance of Sbuject is usually an instance object of the DelegatingSubject class (or subclass). At the beginning of authentication, the securityManager instance set by the application will be entrusted to call the corresponding isPermitted* or hasRole* method.

3. Next, SecurityManager will delegate the built-in Authorizer instance (default is an instance of ModularRealmAuthorizer class, similar to authentication instance, which also supports one or more Realm instance authentication) to call the corresponding authorization method.

4. Each Realm will check whether the same Authorizer interface is implemented. Then, Reaml's own corresponding authorization verification method is called.

When using multiple Realm, unlike authentication policy processing, authorization processing:

1. When an exception occurs in the call to Realm, an exception will be thrown immediately to end authorization verification.

2. As long as there is a successful Realm verification, the authorization will be considered successful and will be returned immediately to end the authentication.

Realm implementation of 4.Shiro

It is mentioned in the internal implementation mechanism of authentication and authorization that the final processing will be handed over to Real. Because in Shiro, it is finally through Realm to obtain the information of users, roles and permissions in the application. Typically, the authentication information needed by Shiro is obtained directly from our data source in Realm. It can be said that Realm is a DAO dedicated to security framework.

I. implementation of authentication

As mentioned earlier, the authentication process for Shiro is eventually handed over to Realm, when the getAuthenticationInfo (token) method of Realm is called.

This method mainly performs the following operations:

1. Check the token information submitted for authentication

2. Get user information from a data source (usually a database) according to token information

3. Match and verify the user information.

4. Verification will return an AuthenticationInfo instance that encapsulates the user's information.

5. If the verification fails, the AuthenticationException exception information is thrown.

What we need to do in our application is to customize a Realm class, inherit the AuthorizingRealm abstract class, overload doGetAuthenticationInfo (), and override the method to get user information.

Java code

Protected AuthenticationInfo doGetAuthenticationInfo (AuthenticationToken authcToken) throws AuthenticationException {

UsernamePasswordToken token = (UsernamePasswordToken) authcToken

User user = accountManager.findUserByUserName (token.getUsername ())

If (user! = null) {

Return new SimpleAuthenticationInfo (user.getUserName (), user.getPassword (), getName ())

} else {

Return null

}

}

II. Implementation of authorization

The authorization implementation is very similar to the authentication implementation. In our custom Realm, we override the doGetAuthorizationInfo () method and override the method to obtain user rights.

Java code

Protected AuthorizationInfo doGetAuthorizationInfo (PrincipalCollection principals) {

String userName = (String) principals.fromRealm (getName ()) .iterator () .next ()

User user = accountManager.findUserByUserName (userName)

If (user! = null) {

SimpleAuthorizationInfo info = new SimpleAuthorizationInfo ()

For (Group group: user.getGroupList ()) {

Info.addStringPermissions (group.getPermissionList ())

}

Return info

} else {

Return null

}

}

Configuration instructions for 5.Shiro

The configuration of Apache Shiro is mainly divided into four parts:

Definition and configuration of objects and attributes filter configuration for URL static user configuration static role configuration

Among them, because the dynamic data of users and roles are generally operated by the background, the Shiro configuration generally includes only the configuration of the first two items.

Most of the components of Apache Shiro are based on POJO, so we can configure them using any POJO-compatible configuration mechanism, such as Java code, Sping XML, YAML, JSON, ini files, and so on. Next, take the configuration of Spring XML as an example, and briefly explain some of the configuration parameters.

Configuration of the Shiro object:

The main purpose of this paper is to define and configure the implementation of each component of Shiro. The main components have been briefly introduced earlier, and we will not explain them one by one here.

Xml code

Configuration of Shiro filter

Shiro is mainly managed through URL filtering, and the configuration here is to specify specific authorization rule definitions.

Xml code

->

# some example chain definitions:

/ admin/** = authc, roles [admin]

/ docs/** = authc, perms [document:read]

/ * * = authc

# more URL-to-FilterChain definitions here

URL filter configuration instructions:

Shiro can implement URL-based authorization verification through configuration files. FilterChain definition format:

URL_Ant_Path_Expression = Path_Specific_Filter_Chain

Each URL configuration indicates that application requests that match the URL will be validated by the corresponding filter.

For example:

[urls]

/ index.html = anon

/ user/create = anon

/ user/** = authc

/ admin/** = authc, roles [administrator]

/ rest/** = authc, rest

/ remoting/rpc/** = authc, perms ["remote:invoke"]

URL expression description

1. The URL directory is based on HttpServletRequest.getContextPath () this directory setting

2. URL can use wildcards, and * * represents any subdirectory

3. When Shiro verifies URL, the matching search will not continue if the URL match is successful. So pay attention to the order of URL in the configuration file, especially when using wildcards.

Filter Chain definition description

1. A URL can be configured with multiple Filter separated by commas

2. When multiple filters are set, all of them are verified before they are passed.

3. Some filters can specify parameters, such as perms,roles

FilterChain built into Shiro

Filter Name

Class

Anon

Org.apache.shiro.web.filter.authc.AnonymousFilter

Authc

Org.apache.shiro.web.filter.authc.FormAuthenticationFilter

AuthcBasic

Org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter

Perms

Org.apache.shiro.web.filter.authz.PermissionsAuthorizationFilter

Port

Org.apache.shiro.web.filter.authz.PortFilter

Rest

Org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter

Roles

Org.apache.shiro.web.filter.authz.RolesAuthorizationFilter

Ssl

Org.apache.shiro.web.filter.authz.SslFilter

User

Org.apache.shiro.web.filter.authc.UserFilter

Integration of 6.Shiro and Spring

First, add shiro filter to web.xml

Xml code

ShiroFilter

Org.springframework.web.filter.DelegatingFilterProxy

ShiroFilter

/ *

2. Add shiro configuration to the applicationContext.xml of Spring

1. Add shiroFilter definition

Xml code

/ login = anon

/ user/** = authc

/ role/edit/* = perms [role:edit]

/ role/save = perms [role:edit]

/ role/list = perms [role:view]

/ * * = authc

/ / loginUrl in shiroFilter is the login page address

SuccessUrl is the address of the login success page (if you first visit the protected URL and log in successfully, then jump to the actual access page)

UnauthorizedUrl authentication failed to access the page (the previously mentioned "unauthorized page").

2. Add securityManager definition

Xml code

3. Add realm definition

Xml code

Third, implement MyRealm: inherit AuthorizingRealm and rewrite authentication and authorization method

Java code

Public class MyRealm extends AuthorizingRealm {

Private AccountManager accountManager

Public void setAccountManager (AccountManager accountManager) {

This.accountManager = accountManager

}

/ * *

* Authorization Information

, /

Protected AuthorizationInfo doGetAuthorizationInfo (

PrincipalCollection principals) {

String username= (String) principals.fromRealm (getName ()). Iterator (). Next ()

If (username! = null) {

User user = accountManager.get (username)

If (user! = null & & user.getRoles ()! = null) {

SimpleAuthorizationInfo info = new SimpleAuthorizationInfo ()

For (SecurityRole each: user.getRoles ()) {

Info.addRole (each.getName ())

Info.addStringPermissions (each.getPermissionsAsString ())

}

Return info

}

}

Return null

}

/ * *

* Authentication information

, /

Protected AuthenticationInfo doGetAuthenticationInfo (

AuthenticationToken authcToken) throws AuthenticationException {

UsernamePasswordToken token = (UsernamePasswordToken) authcToken

String userName = token.getUsername ()

If (userName! = null & &! ".equals (userName)) {

User user = accountManager.login (token.getUsername ()

String.valueOf (token.getPassword ())

If (user! = null)

Return new SimpleAuthenticationInfo (

User.getLoginName (), user.getPassword (), getName ()

}

Return null

}

}

The answers to the questions on how to analyze Shiro are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.