Shiro actual combat series (II): introduction to actual combat (Continued)

Next, we will explain a series based on actual combat, so the relevant java files can obtain POM XML and its log4j files are also applicable to this explanation.

1、 Using Shiro

Using Shiro now our securitymanager has been set up and can be used. Now we can start doing something we really care about - performing security operations. When protecting our application, the most relevant question we may ask ourselves is "who is the current user" or "whether the current user is allowed to do XXX". When we write code or design user interfaces, it is common to ask these questions: applications are usually built based on the user's background, And you want to embody (guarantee) functions based on each user standard. Therefore, the most natural way for us to consider application security is based on the current user. Shiro's API uses its subject concept, which fundamentally represents the concept of "current user".

In almost all environments, you can obtain the currently executing user through the following call:

Using securityutils Getsubject(), we can get the currently executing subject. Subject is a security term, which basically means "the specific security view of the user currently executing". It is not called "user" because the word "user" is usually associated with humans. In the security world, the term "subject" can be expressed as human, and it can be a third-party process, cron job, daemon account, or other similar things. It simply means that "the thing is currently interacting with software". For most purposes and purposes, you can think of subject as Shiro's "user" concept.

GetSubject () is invoked in a separate application, which can return a Subject based on user data in the application specific location, and in the server environment (for example, Web application), the Subject it acquires is based on the user data associated with the current thread or incoming request.

2、 Now that you have a subject, what can you do with it?

If you want to make things available to users in the current session of the application, you can get their session:

Session is a specific instance of Shiro. It provides most of the things you often use with httpsessions, except for some additional benefits and a huge difference: it does not need an HTTP environment! If deployed inside a web application, the default session will be based on httpsession. But in a non web environment, like this simple tutorial application, Shiro will automatically use its enterprise session management by default. This means that you will use the same API in your application, at any tier, regardless of the deployment environment! This opens up a new world of applications, because any application that needs a session no longer has to be forced to use httpsession or EJB stateful session beans. Also, any client technology can now share session data.

3、 So now you can get a subject and their session. If they are allowed to do something, such as checking roles and permissions, where is "checking" really useful?

Well, we can only do these checks for a known user. The subject instance above represents the current user, but who is the current user? Well, they are anonymous - that is, until they log in at least once. So let me do something like this:

For example,

Who are they

Determine whether they have a specific role:

You can also determine whether they have permission to operate on an entity of a certain type:

Finally, when users have finished using the application, they can log out:

The full version of the above code is as follows:

The above is a complete example, as follows:

Load the configuration file Shiro. From the creation factory Init to create the security manager, to obtain the current user, and to save the user instance with session.

Then go to obtaining user instances and obtaining user roles and their corresponding permissions