后端同事改了登录接口导致我五分钟刷新一次。。。--工作经验之用户登录设计

最近开始做新项目，是一个toC项目，之前的登录接口是一个实习生写的，偶然间另一位同事看了看项目代码之后跟我说为了提高安全性，修改了登录接口。。。

背景

博主在做的一个项目之前的登录接口是实习生写的，登录设计就是简单的提交用户名密码获取token，然后token的过期时间巨长是30天，于是乎另一位工作年限长一点的同事修改了代码，变成了登录获取两个token：

• 1.accessToken: 真正用来获取数据的权限
• 2.refreshToken: 用来获取accessToken

为什么需要双token?

总所周知，token是为了防止用户信息传来传去导致被劫持，但是假如token没有过期时间或者过期很长，那么显然token被劫持还是不安全的，token就失去了意义。

所以这时候大家肯定都想：那么把token过期时间设置的短一点就行啦？

是的，一般来讲accessToken的过期时间应该要短一点，但是这时候对于用户来讲就麻烦了。

因为token过期就意味着要重新登录，想象下你正浏览的好好的，突然让你掉线了并且要求你重新登录，心里肯定是想骂人的。

什么时候需要用户重新登录？

主要有三种情况：

• 1.用户长时间无操作，也可以定义未不活跃用户，就会被自动踢下，自动重定向到登录页面，超时时间可以自定义设置；
• 2.token失效，通常是双token都失效后，会要求重新登录获取新的双token；
• 3.当检测到有风险的时候，可以要求重新登录，获取token；

因此这时候就可以使用双token的设计，当两个token都过期了再要求用户重新登录，对于refreshToken，它只用来获取accessToken,不会频繁被用于请求，对于accessToken，它过期时间非常短，即使被拦截了解密也需要时间，而token本身也很快过期，因此这样的设计更加安全。

那么就这样就皆大欢喜了吗？显然不是作为前端，我们还需要实现让用户对于使用refreshToken获取accessToken的操作是无感的。

refreshToken获取token无感刷新?

总的来说一般有三种方法：

• 1.通过后端返回过期时间，前端根据当前时间与这个过期时间做判断,去调用刷新token接口

  缺点：需要后端额外提供一个Token过期时间的字段；使用了本地时间判断，若本地时间被篡改，特别是本地时间比服务器时间慢时，拦截会失败。

• 2.定时任务，定时使用refreshToken获取accessToken

  浪费资源,消耗性能,不建议采用。

• 3.做响应拦截器中拦截，后端判断token 返回过期后，调用刷新token接口

  比较好的方案，也是我在项目中使用的方案，并且axios有做响应拦截的api

这里贴一个简单的实现demo:

import axios from 'axios';

axios.interceptors.response.use(res => {
        // token异常
        if (res.data.code === 409) {
            deleteToken();
            router.push('/login')
            return Promise.reject();
            // 更新Token
        } else if (res.data.code === 410) {
            const {token} = res.data
            setToken(token);// 重置token
        }
        return res && res.data
    }
)

总结

为了用户安全因此要使用token设计，为了解决用户频繁登录，采用双token设计，同时前端也需要做一定处理。