foreword
This article introduces the user login process and technical implementation through diagrams and codes, including user login, user verification, how to obtain operating user information, and how to avoid verification related implementations of blacklist and anonymous interfaces.
It is better to eat with the relevant knowledge of the gateway
business diagram
For user login, it involves several aspects of user registration and login verification, and demonstrates how to handle (new user/old user) login through the flow chart
Process Interpretation
-
Client-login interface (usually mobile phone verification code login)
1. Fill in the mobile phone number 2. Send the verification code 3. Fill in the verification code 4. Check the automatic registration of new users
-
Server-User Authentication
1. Verify that the account verification code is correct 2. Verify that the user exists (initialized user information does not exist) 3. Complete the verification and generate a token 4. Return the token to the client
user information design
| field | describe | type | Is it unique |
|---|---|---|---|
| telephone | Phone number | varchar | yes |
| nickname | Nick name | varchar | Whether it can be repeated according to the business decision |
| account | account | varchar | yes |
| password | password | varchar | no |
| create_time | creation time | datetime | no |
| modify_time | Change the time | datetime | no |
| ...Omit the authorization code of the applet, etc., and add it according to your own business |
Verification Flow Diagram
The login verification process involves two interfaces and two caches. 1. Obtain the verification code interface, send the verification code to the mobile phone number and set the verification code cache, and set the expiration time; 2. Log in to the interface, submit the mobile phone number and verification code, read the cache for matching verification, and generate a token and return it to the client if successful , the client logs in successfully. After logging in, the request header carries the token to make a business request.
About token expiration time
Usually the expiration time of our token is defined according to the type of client. The expiration time of the app will be longer (usually one week). The expiration time of the web side is in hours. If the expiration time is controlled, the web login and app login can be separated. It can be divided into two interfaces (which can be split, and the interface pressure is less), or it can be judged according to the request header information. It is set for 7 days on the mobile end, and two hours on the web end.
About business request token verification
After the login is successful, the client will carry the token every time it requests. Usually, we will have a gateway for token verification. The core of the gateway for login verification is the token written after the login is successful as the key, which is the cache of the user's basic information. The diagram is as follows:
验证成功后，重写内部请求头，将用户的的id,账号，昵称信息放入请求头中，这样可以方便业务系统获取当前操作用户信息以及权限控制等等
关于登出操作
用户携带token请求登出接口，登出接口对token对应的缓存进行删除操作，返回401即可，客户端获取到401就会跳转到登录页面
关于匿名请求(免登录)
通常匿名请求放行有两种方案，1.授权token,为token设置单位时间内请求次数;2.配置路径放行规则，对请求接口路径进行正则匹配，符合正则规则的进行放行
方案1：授权token，限制单位时间请求次数
优点就是虽然是免登录接口，但是接口的操作对象可以追溯，请求次数可控，避免被非法利用；缺点就是需要更多的编码及配置工作
技术实现
-
1.提供一个授权token管理页面，主要管理token使用者，token的值，单位时间访问次数(如每分钟60次)
-
2.增删改查，将授权token存放到缓存中，使用map进行存储，key为token，值为每分钟访问次数
-
3.单位时间计数缓存,过期时间为1分钟
这时候我们需要在上面的验证流程图基础上进行升级
请求次数检查代码实现
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
import java.util.concurrent.TimeUnit;
/**
-
授权token请求限制缓存
-
@author 热黄油啤酒
-
@since 2021-11-01
*/public class AuthTokenRequestLimitCache {private RedisTemplate<String, Integer> redisTemplate;
private static final String AUTH_TOKEN_LIMIT_KEY_PREFIX = "auth_token_limit";
/**
- 请求次数+1并检查是否超限
- @param token
- @return 是否放行
*/public boolean incrementWithCheck(String token) { // 1.获取token请求次数限制，获取为null代表授权配置已被修改，此token已经不具备权限Integer limit = getLimit(token);if (limit == null) { return false;
}// 2.组装缓存key，读取缓存String key = String.join(":", AUTH_TOKEN_LIMIT_KEY_PREFIX, token);Integer count = redisTemplate.opsForValue().get(key);// 3.没有值代表一分钟内没有请求产生了if (count == null) { // 初始化值
redisTemplate.opsForValue().increment(key);// 设置过期时间
redisTemplate.expire(key, 1L, TimeUnit.MINUTES);return true;
}// 自增并获取当前值 大于限制的话 返回false 网关过滤器返回提示信息(如请求过于频繁)Long inc = redisTemplate.opsForValue().increment(key);return inc <= limit;
}
/**
- 获取限值
- @param token
@return
*/public Integer getLimit(String token) { Object limit = redisTemplate.opsForHash().get("auth_token_limit", token);return limit == null ? null : (Integer) limit;
}
}复制代码
对于授权接口，通常是只允许get操作，对数据进行提交或者更新是不被允许的，当然这个是业务层面的，最终取决于系统设计
方案2：请求路径正则校验
我们在网关的配置文件中增加匿名接口规则，请求到网关时，检查请求的路径是否符合匿名接口规则，是则放行，不是则进行token校验，方案比较简单，只需要对网关进行处理即可。
关于黑名单
对于一个系统来说，黑名单是最后一道关卡，所以为了安全我们需要对问题用户进行黑名单操作，具体实现也比较简单
- 1.用户管理页面提供一个拉黑的按钮，拉黑后，这些用户的id会存储到一个set集合中去
- 2.登录时候检查用户是否在黑名单中，是则拒绝登录并提示
- 3.如果用户已经登录后进行拉黑操作，网关会在鉴权通过后检查用户是否在黑名单中，是则删除token对应缓存，返回401,401就会跳到登录页，步骤2就会进行拦截。
总结
The user system is a very basic system, but many programmers may not really participate in the development of the user system in their work. Through this article, you can have a comprehensive understanding of the user login process and supporting functions.