輕輕鬆鬆搞定分佈式 Token 校驗
作者：The_way_inf
原文：https://blog.csdn.net/FUTEROX/article/details/127288002
前言
那麼今天帶來的其實也沒啥，就是簡簡單單的校驗，去校驗 token，然後就好了，但是區別是啥呢，咱們這邊有個大冤種就是這個 GateWay。此外這邊的全部代碼都是在 WhiteHolev0.7 裏面的，可見的。
由於這個玩意，咱們不好再像以前直接去在攔截器裏面去搞事情。而且說實話，請求那麼多，如果全部都在 GateWay 去做的話，我是真的懶得去寫那些啥配置了，到時候放行哪些接口都會搞亂。
所以問題背景就是在分佈式微服務的場景下，如何去更好地校驗 token。並且通過我們的 token 我們可以做到單點登錄。
那麼這個時候我們就不得不提到我們上篇博文提到的內容了：
- https://blog.csdn.net/FUTEROX/article/details/127232757
當然重點是登錄模塊。
token 存儲
既然我們要校驗，那麼我們要做的就是拿到這個 token，那麼首先要做的就是生成 token，然後存儲 token，咱們上一篇博文已經說的很清楚了，甚至還給出了對應的工具類。我們的流程是這樣的：
那麼在這裏的話，和先前不一樣的是，由於咱們的這個其實是一個多端的，所以的話咱們不僅僅有 PC 端還有移動端（當然移動端的作者也是我這個大冤種）所以 token 的話也是要做到多端的。那麼這樣的話，我們就要對上次做一點改動。
這裏的話，和上次不一樣的地方有兩個。
Token 存儲實體
這裏新建了一個 token 的實體，用來存儲到 redis 裏面。
@Data
@AllArgsConstructor
@NoArgsConstructor
public class LoginToken {
//這個是我們的存儲Redis裏面的Token
private String PcLoginToken;
private String MobileLoginToken;
private String LoginIP;
}login 業務代碼
之後就是我們修改後的代碼了。這個也就是和先前做了一點改動，主要是做多端的 token 嘛。
@Service
public class loginServiceImpl implements LoginService {
@Autowired
UserService userService;
@Autowired
RedisUtils redisUtils;
//爲安全期間這裏也做一個20防刷
@Override
public R Login(LoginEntity entity) {
String username = entity.getUsername();
String password = entity.getPassword();
password=password.replaceAll(" ","");
if(redisUtils.hasKey(RedisTransKey.getLoginKey(username))){
return R.error(BizCodeEnum.OVER_REQUESTS.getCode(),BizCodeEnum.OVER_REQUESTS.getMsg());
}
redisUtils.set(RedisTransKey.setLoginKey(username),1,20);
UserEntity User = userService.getOne(
new QueryWrapper<UserEntity>().eq("username", username)
);
if(User!=null){
if(SecurityUtils.matchesPassword(password,User.getPassword())){
//登錄成功，簽發token,按照平臺類型去簽發不同的Token
String token = JwtTokenUtil.generateToken(User);
//登錄成功後，將userid--->token存redis，便於做登錄驗證
String ipAddr = GetIPAddrUtils.GetIPAddr();
if(entity.getType().equals(LoginType.PcType)){
LoginToken loginToken = new LoginToken(token,null,ipAddr);
redisUtils.set(RedisTransKey.setTokenKey(User.getUserid()+":"+LoginType.PcType)
,loginToken,7, TimeUnit.DAYS
);
return Objects.requireNonNull(R.ok(BizCodeEnum.SUCCESSFUL.getMsg())
.put(LoginType.PcLoginToken, token))
.put("userid",User.getUserid());
}else if (entity.getType().equals(LoginType.MobileType)){
LoginToken loginToken = new LoginToken(null,token,ipAddr);
redisUtils.set(RedisTransKey.setTokenKey(User.getUserid()+":"+LoginType.MobileType)
,loginToken,7, TimeUnit.DAYS
);
return Objects.requireNonNull(R.ok(BizCodeEnum.SUCCESSFUL.getMsg())
.put(LoginType.PcLoginToken, token))
.put("userid",User.getUserid());
} else {
return R.error(BizCodeEnum.NUNKNOW_LGINTYPE.getCode(),BizCodeEnum.NUNKNOW_LGINTYPE.getMsg());
}
}else {
return R.error(BizCodeEnum.BAD_PUTDATA.getCode(),BizCodeEnum.BAD_PUTDATA.getMsg());
}
}else {
return R.error(BizCodeEnum.NO_SUCHUSER.getCode(),BizCodeEnum.NO_SUCHUSER.getMsg());
}
}
}枚舉類修改
同樣的這裏和先前的枚舉類有一點不一樣，主要是多了一點東西。
public enum BizCodeEnum {
UNKNOW_EXCEPTION(10000,"系統未知異常"),
VAILD_EXCEPTION(10001,"參數格式校驗失敗"),
HAS_USERNAME(10002,"已存在該用戶"),
OVER_REQUESTS(10003,"訪問頻次過多"),
OVER_TIME(10004,"操作超時"),
BAD_DOING(10005,"疑似惡意操作"),
BAD_EMAILCODE_VERIFY(10007,"郵箱驗證碼錯誤"),
REPARATION_GO(10008,"請重新操作"),
NO_SUCHUSER(10009,"該用戶不存在"),
BAD_PUTDATA(10010,"信息提交錯誤，請重新檢查"),
NOT_LOGIN(10011,"用戶未登錄"),
BAD_LOGIN_PARAMS(10012,"請求異常！觸發5次以上賬號將保護性封禁"),
NUNKNOW_LGINTYPE(10013,"平臺識別異常"),
BAD_TOKEN(10014,"token校驗失敗"),
SUCCESSFUL(200,"successful");
private int code;
private String msg;
BizCodeEnum(int code,String msg){
this.code = code;
this.msg = msg;
}
public int getCode() {
return code;
}
public String getMsg() {
return msg;
}
}當然同樣的，多的東西還有幾個異常類，這個其實就是繼承了 Exception。
/**
* 校驗用戶登錄時，參數不對的情況，此時可能是惡意爬蟲
* */
public class BadLoginParamsException extends Exception{
public BadLoginParamsException(){}
public BadLoginParamsException(String message){
super(message);
}
}public class BadLoginTokenException extends Exception{
public BadLoginTokenException(){}
public BadLoginTokenException(String message){
super(message);
}
}public class NotLoginException extends Exception{
public NotLoginException(){}
public NotLoginException(String message){
super(message);
}
}其他的倒還是和先前的保持一致。
存儲效果
那麼到此我們在登錄部分完成了對 token 的存儲，但是這個是在服務端，現在這個玩意已經存到了咱們的 redis 裏面：
客戶端存儲
現在我們服務端已經存儲好了，那麼接下來就是要在客戶端進行存儲。這個也好辦，我們直接來看到完整的用戶登錄代碼就知道了。
<template>
<div>
<el-form :model="formLogin" :rules="rules" ref="ruleForm" label-width="0px" >
<el-form-item prop="username">
<el-input v-model="formLogin.username" placeholder="賬號">
<i slot="prepend" class="el-icon-s-custom"/>
</el-input>
</el-form-item>
<el-form-item prop="password">
<el-input type="password" placeholder="密碼" v-model="formLogin.password">
<i slot="prepend" class="el-icon-lock"/>
</el-input>
</el-form-item>
<el-form-item prop="code">
<el-row :span="24">
<el-col :span="12">
<el-input v-model="formLogin.code" auto-complete="off" placeholder="請輸入驗證碼" size=""></el-input>
</el-col>
<el-col :span="12">
<div class="login-code" @click="refreshCode">
<!--驗證碼組件-->
<s-identify :identifyCode="identifyCode"></s-identify>
</div>
</el-col>
</el-row>
</el-form-item>
<el-form-item>
<div class="login-btn">
<el-button type="primary" @click="submitForm()" style="margin-left: auto;width: 35%">登錄</el-button>
<el-button type="primary" @click="goRegister" style="margin-left: 27%;width: 35%" >註冊</el-button>
</div>
</el-form-item>
</el-form>
</div>
</template>
<script>
import SIdentify from "../../components/SIdentify/SIdentify";
export default {
name: "loginbyUserName",
components: { SIdentify },
data() {
return{
formLogin: {
username: "",
password: "",
code: ""
},
identifyCodes: '1234567890abcdefjhijklinopqrsduvwxyz',//隨機串內容
identifyCode: '',
// 校驗
rules: {
username:
[
{ required: true, message: "請輸入用戶名", trigger: "blur" }
],
password: [
{ required: true, message: "請輸入密碼(區分大小寫)", trigger: "blur" }
],
code: [
{ required: true, message: "請輸入驗證碼", trigger: "blur" }
]
}
}
},
mounted () {
// 初始化驗證碼
this.identifyCode = ''
this.makeCode(this.identifyCodes, 4)
},
methods:{
refreshCode () {
this.identifyCode = ''
this.makeCode(this.identifyCodes, 4)
},
makeCode (o, l) {
for (let i = 0; i < l; i++) {
this.identifyCode += this.identifyCodes[this.randomNum(0, this.identifyCodes.length)]
}
},
randomNum (min, max) {
return Math.floor(Math.random() * (max - min) + min)
},
submitForm(){
if (this.formLogin.code.toLowerCase() !== this.identifyCode.toLowerCase()) {
this.$message.error('請填寫正確驗證碼')
this.refreshCode()
}
else {
//這邊後面做一個提交，服務器驗證，通過之後獲得token
this.axios({
url: "/user/user/login",
method: 'post',
data:{
"username":this.formLogin.username,
"password":this.formLogin.password,
"type": "PcType",
}
}).then((res)=>{
res = res.data
if (res.code===10001){
alert("請將對應信息填寫完整！")
}else if(res.code===0){
alert("登錄成功")
localStorage.setExpire("LoginToken",res.PcLoginToken,this.OverTime)
localStorage.setExpire("userid",res.userid,this.OverTime)
this.$router.push({ path: '/userinfo', query: {'userid':res.userid} });
}else {
alert(res.msg);
}
})
}
},
goRegister(){
this.$router.push("/register")
}
},
}
</script>
<style scoped>
</style>這裏的話，咱們對localStorage做了一點優化：
這個代碼是在 main.js 直接搞的。
Storage.prototype.setExpire=(key, value, expire) =>{
let obj={
data:value,
time:Date.now(),
expire:expire
};
localStorage.setItem(key,JSON.stringify(obj));
}
//Storage優化
Storage.prototype.getExpire= key =>{
let val =localStorage.getItem(key);
if(!val){
return val;
}
val =JSON.parse(val);
if(Date.now()-val.time>val.expire){
localStorage.removeItem(key);
return null;
}
return val.data;
}這個 this.OverTime 就是一個全局變量，就是 7 天過期的意思。
token 驗證
前面咱們說完了這個存儲，那麼現在的話咱們就是驗證服務了。首先我們來看到什麼地方需要驗證。
我們拿這個爲例子：
前端提交
<script>
export default {
name: "myspace",
data() {
return {
}
},
created() {
//先對token再進行驗證
let loginToken = localStorage.getExpire("LoginToken");
let userid = localStorage.getExpire("userid");
//這個只有用戶自己才能進入，自己只能進入自己對應的MySpace
if(loginToken==null && userid==null){
alert("檢測到您未登錄，請先登錄")
this.$router.push({path: "/login"});
}else {
//發送token驗證token是否正常，否則一樣不給過
this.axios({
url: "/user/user/space/isLogin",
method: 'get',
headers: {
"userid": userid,
"loginType": "PcType",
"loginToken": loginToken,
},
params: {
'userid': userid,
}
}).then((res)=>{
res = res.data;
if (!(res.code === 0)) {
alert(res.msg)
this.$router.push({path: "/login"});
}
}).catch((err)=>{
alert("未知異常，請重新登錄")
this.$router.push({path: "/login"});
});
}
}
}
</script>後端校驗
ok，現在咱們可以來聊聊這個後端的校驗了，這個還是很重要的，也是咱們今天的主角。
那麼在開始的時候咱們說了這個使用攔截器的方案並不是可行的，而且在後面可能我們還需要在業務處理的時候拿到 token 去解析裏面的東西，完成一些處理，到時候在攔截器的時候也不好處理。
而且重點是並不是所有的接口都要的，但是也不是少部分的接口不要，這 TM 就尷尬了，那麼如何破局。那麼此時我們就需要定位到每一個具體的方法上面，那麼問題不就解決了，這個咋搞，誒嘿，搞個切面 + 註解不就完了。
自定義註解
先定義一個註解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface NeedLogin {
String value() default "";
}這個註解我放在了 common 組件下：
切面處理
那麼之後就是咱們的切面了，我們剛剛定義的異常處理類都是在這個切面上處理的。
public class VerificationAspect {
@Autowired
RedisUtils redisUtils;
@Pointcut("@annotation(com.huterox.common.holeAnnotation.NeedLogin)")
public void verification() {}
/**
* 環繞通知 @Around ,當然也可以使用 @Before (前置通知) @After (後置通知)就算了
* @param proceedingJoinPoint
* @return
* 我們這裏再直接拋出異常，反正有那個誰統一異常類
*/
@Around("verification()")
public Object verification(ProceedingJoinPoint proceedingJoinPoint) throws Throwable{
RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
ServletRequestAttributes servletRequestAttributes = (ServletRequestAttributes) requestAttributes;
assert servletRequestAttributes != null;
HttpServletRequest request = servletRequestAttributes.getRequest();
//分登錄的設備進行驗證
String loginType = request.getHeader("loginType");
String userid = request.getHeader("userid");
String tokenUser = request.getHeader("loginToken");
String tokenKey = RedisTransKey.getTokenKey(userid + ":" + loginType);
if(tokenUser==null || userid==null || loginType==null){
throw new BadLoginParamsException();
}
if(redisUtils.hasKey(tokenKey)){
if(loginType.equals(LoginType.PcType)){
Object o = redisUtils.get(tokenKey);
LoginToken loginToken = JSON.parseObject(o.toString(), LoginToken.class);
if(!loginToken.getPcLoginToken().equals(tokenUser)){
throw new BadLoginTokenException();
}
}else if (loginType.equals(LoginType.MobileType)){
Object o = redisUtils.get(tokenKey);
LoginToken loginToken = JSON.parseObject(o.toString(), LoginToken.class);
if(!loginToken.getMobileLoginToken().equals(tokenUser)){
throw new BadLoginTokenException();
}
}
}else {
throw new NotLoginException();
}
return proceedingJoinPoint.proceed();
}
}使用
那麼接下來就是使用了。我們來看到這個：
這個是我們的 controller，作用就是用來檢驗這個用戶本地的 token 對不對的，那麼實現的服務類啥也沒有：
之後我們來看到咱們的一個效果：
可以看到在進入頁面的時候，鉤子函數會請求咱們的這個接口，然後的話，咱們通過這個接口的話可以看到驗證的效果。這裏驗證通過了。
總結
讓我康康這篇文章的效果咋樣，If it works well, I’ll take out my development log directly and go to Bling Bling your eyes.！
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/d-AmadKKGzcm5IEaSdo5Og