Front-end address: https://github.com/wang926454/VueStudy/tree/master/VueStudy08-JWT
If you have any questions, please scan the code and join the QQ group to communicate: 779168604
- First, post the username and password to user/login to log in. If successful, the encrypted AccessToken will be returned. If failed, a 401 error will be returned directly (the account or password is incorrect).
- Just bring this AccessToken with you for future visits.
- The authentication process mainly rewrites Shiro 's entry filter JWTFilter ( BasicHttpAuthenticationFilter ) to determine whether the request header contains the Authorization field.
- If yes, perform Shiro 's Token login authentication and authorization (every request for user access that requires permission must add the Authorization field in the header to store the AccessToken ), if not, use direct access as a visitor (if there is permission control, visitor access will be intercepted)
Most of them solve this problem in the form of MD5 + salt (details from Baidu). I use AES-128 + Base64 to encrypt the password in the form of account + password. Because the account is unique, the same structure will not appear. The problem of secret password
Originally, JedisUtil was directly injected as a Bean . Every time it is used, it can be injected directly
@Autowired
. However, after rewriting Shiro 's CustomCache , JedisUtil could not be injected, so it was changed to static injection into the JedisPool connection pool . The JedisUtil tool class still directly calls the static method. No need for@Autowired
injection
- After the login authentication is passed, the AccessToken information is returned ( the current timestamp and account number are saved in the AccessToken )
- At the same time, set a RefreshToken in Redis with the account as the Key and the Value as the current timestamp (login time)
- Now during authentication, the AccessToken must not have expired and the corresponding RefreshToken must exist in Redis , and the RefreshToken timestamp must be consistent with the timestamp in the AccessToken information before the authentication is passed. This can achieve the controllability of JWT.
- If you log in again and obtain a new AccessToken , the old AccessToken cannot be authenticated, because the RefreshToken timestamp information stored in Redis will only be consistent with the timestamp carried in the latest generated AccessToken information , so each user can only use The latest AccessToken certification
- Redis 's RefreshToken can also be used to determine whether a user is online. If a Redis RefreshToken is deleted, the AccessToken corresponding to this RefreshToken will no longer be able to pass authentication. This is equivalent to controlling the user's login and eliminating the user.
- The expiration time of AccessToken itself is 5 minutes (configurable in the configuration file), and the expiration time of RefreshToken is 30 minutes (configurable in the configuration file)
- When 5 minutes have passed after logging in, the current AccessToken will expire. If you bring the AccessToken again to access JWT, a TokenExpiredException exception will be thrown, indicating that the Token has expired.
- Start to determine whether to refresh the AccessToken . Redis queries whether the current user's RefreshToken exists , and whether the timestamp carried by this RefreshToken is consistent with the timestamp carried by the expired AccessToken.
- If it exists and is consistent, refresh the AccessToken, set the expiration time to 5 minutes (configurable in the configuration file), the timestamp to the latest timestamp, and also set the timestamp in the RefreshToken to the latest timestamp, and refresh the expiration time to 30 again. Expiration in minutes (configurable in configuration file)
- Finally, the refreshed AccessToken is stored in the Authorization field in the Header of the Response and returned (the front end obtains and replaces it, and uses the new AccessToken for access next time)
First configure the srcmainresourcesgeneratorgeneratorConfig.xml file (the default configuration is under the reverse package at the lower level of the original package), and execute it in the command line window of the pom.xml level directory (that is, under the project root directory) (The premise is that mvn is configured) (IDEA can be executed directly by double-clicking in the Maven window Plugins)
mvn mybatis-generator:generate
先设置Content - Type为application / json
然后填写请求参数帐号密码信息
进行请求访问,请求访问成功
点击查看Header信息的Authorization属性即是Token字段
访问需要权限的请求将Token字段放在Header信息的Authorization属性访问即可
Token的自动刷新也是在Token失效时返回新的Token在Header信息的Authorization属性