I. Introduction
The key to the whole article is to know whose method the doGetAuthenticationInfo method rewritten by the ShiroRealm class is.
From the above figure, we can know that ShiroRealm finally inherited the method of AuthenticatingRealm.
2. Custom ShiroRealm class
ps: The note on ① in the picture is a preconceived understanding when you haven’t seen the bottom layer.
In the custom ShiroRealm, it looks like verification is ①, but only one is created SimpleAuthenticationInfo对象
, and finally ②returns out and disappears.
As a novice, I tried Debug to find the actual code to be executed, but only jumped to the SimpleAuthenticationInfo class, and finally found nothing.
Let's look back at ShiroRealm, which inherits AuthorizingRealm and
enters AuthorizingRealm. You will find that there is still nothing, but you will notice that it inherits AuthenticatingRealm (their relationship is as shown in the preface).
3. AuthenticatingRealm class
In this class, it can be found through Find that the AuthenticatingRealm class contains abstract methods doGetAuthenticationInfo
, which means that @Override in ShiroRealm is it.
Let's see who called this method, and finally we can find that in the AuthenticatingRealm class, getAuthenticationInfo()
② in the method calls this method; that is, the content of our return in ShiroRealm is here.
Speaking of which, let's look at ① and ③ respectively.
1. getCachedAuthenticationInfo(token) method
① From the literal meaning, the parameter and the class name of the final object, we can know that this is to obtain the user name and password in the token.
- Supplement: Friends with sharp eyes will find that in the above figure, both ① and ② are returned
info
(AuthenticationInfo class); the code logic is:
// 通过缓存和token获取用户信息
info = getCachedAuthenticationInfo(token);
// 用户信息不存在
if(info == null){
// 在ShiroRealm中@Override,获取登录用户的信息
info = doGetAuthenticationInfo(token);
...
}
The AuthenticationInfo class (as shown in the figure below) is somewhat similar to AuthenticationToken. You can expand it to see the shiro AuthenticationToken system .
getCachedAuthenticationInfo mainly looks at the cache and token to obtain user information.
2, assertCredentialsMatch(token, info) method
In this method CredentialsMatcher()
, although I don't know what it is, the method of the object is called in the following if cm.doCredentialsMatch(token, info)
.
From the interface, you can see that there are 4 implementation classes, not much nonsense, after reading them one by one, I found that the first one only returns true, the second handles those with salt, the fourth handles those without salt, and the third one returns too much. I didn't look closely after a long time.
In contrast, salt should be what we are looking for.
ps: Encryption is a bit difficult for Xiaobai, so I won’t go into it for the time being. Those who are interested can go and have a look.
As you can see here, we know that doCredentialsMatch
in the method, the data decrypted by the token is the same as the data in the database, and true will be returned, which means that the verification is passed.
If false is returned, it will be thrown IncorrectCredentialsException
(see the first picture of the assertCredentialsMatch(token, info) method), and the exception will be caught in the controller and returned to the front end.