大家都知道，用户初次打开客户端时，只是一介平民，毫无身份特权可言。
当用户将正确的账号以及密码，呈递给服务端进行检验，待检验成功之后，服务器端便会亲手打造一个名为Token的令牌，并给予客户端。
客户端自此便拥有了身份，也拥有了符合身份的资源请求权限……
但，Token是有时间限制的！关于时间的设置不宜过长，这样不够安全。更不宜过短，这样会让用户频繁登陆，遭受吐槽！
那有没有什么比较好的解决方案？有，通过无感刷新token！即token在更新时用户无感知，从而避免用户的频繁登陆。
关于无感刷新网上一般有三种解决方案：
- 方案一：后端返回过期时间，前端判断token过期时间,去调用刷新token接口
缺点：需要后端额外提供一个Token过期时间的字段；使用了本地时间判断，若本地时间被篡改，特别是本地时间比服务器时间慢时，拦截会失败。 - 方案二：写个定时器，定时刷新Token接口
缺点：浪费资源,消耗性能,不建议采用。 - 方案三：在响应拦截器中拦截，判断Token 返回过期后，调用刷新token接口
以上三种解决方案都是建立在前端调用后端刷新Token接口的基本之上的。虽然可以解决Token的时间设置问题，但是无形中又增加了前端代码的冗余量。比如：请求时需要增加中间变量防止多次刷新token；同时发起两个或者两个以上的请求时，需要借助Promise安排Token刷新接口的调用顺序。
其实Token也是需要设计的，只要设计的合理，也可大大减少后续的烦恼：
后端在创建Token时，可以将时间设置为Token生成时间，请求过期时间，刷新token过期时间，以及总体过期时间(根据项目需求而定)。四个时间的关系：
请求时间是否在总体过期时间内，如果不在则告知前端Token异常，并让用户重新登陆。如果在则判断请求时间是否过期。
请求时间一旦过期，查看时间是否在刷新token的允许时间内，如果在则重新生成token并响应给前端，前端更新Token。如果不在则告知前端Token异常，并让用户重新登陆。
后端实现：略
前端大体实现：
import axios from 'axios';
axios.interceptors.response.use(response => {
// token异常
if (response.data.code === 409) {
removeToken();// 删除token
router.push('/login');
return Promise.reject("token异常");
} else if (response.data.code === 410) {// 服务端Token更新
const {token} = res.data
setToken(token);// 重置token
}
return response && response.data
}
)
以上是个人对开发中使用Token的一点总结，如有叙述不当之处请指正，我将及时改正并感谢！
网友评论