项目中后端设置的过期时间为24h，测试时我们可以手动修改token值让Token失效
处理方式：
我们观察前面的功能的话，接口的响应信息中是有三个和token相关的信息的
响应拦截器 会在响应接收完毕，在对应请求处理前被拦截器拦截，响应拦截器参数response中保存了相应的信息
那么我们接来下将响应拦截器设置到utils/request.js中，将axios更改为创建的request（因为我们使用了ESLint规范，记得去除所有的分号）
错误处理 ，需要在拦截器中找到特定的错误情况进行token刷新
当出现错误时，通过Elemnt的Message组件设置提示，这里我们采用的是引入方式操作
HTTP 状态码401表示未授权，导致401的情况有：
首先要检测store是否有user信息（有就证明是正常登陆，一定存在的有refresh_token），如果存在的有refresh_token的话就请求新的access_token，需要用到对应的刷新 接口 ，接下来检查是否有新的access_token
如果页面中存在多个请求（大多数页面中都不会只有一次请求），如果Token过期，每个请求都会刷新Token，这个时候刷新多次都没有意义，又增加了请求个数，还会出现额外的问题
通过浏览器的开发者工具观察，有两次的刷新Token请求，由于两次的刷新token携带的refresh_token相同，会导致一次成功一次失败，失败的那一次会导致页面跳转请求页
虽然刷新Token的问题解决了，但是之前发送的两个请求只有一个成功执行，其他的请求都被阻止了
如何解决？
我们声明一个数组存储所有被挂起的请求，当Token刷新完毕再将这些请求重新发送
解决
token过期了需要重新获取新的。Token用于进行接口鉴权，但是Token具有由后端设置的过期时间，当Token过期以后，就无法再请求数据了。
处理方式：
方式1：用户重新登录，获得新的Token就可以了，但是当过期时间较短的时候，每次都是要重新登录操作的，体验很差为了提高用户的信息安全性，Token的过期时间都比较短（就算万一泄露了，过一会儿也就过期无效化了）。
方式2：根据用户信息，自动给用户生成新的Token，减少登录次数。
业务场景
在前后分离场景下，越来越多的项目使用token作为接口的安全机制，APP端或者WEB端（使用VUE、REACTJS等构建）使用token与后端接口交互，以达到安全的目的。本文结合stackover以及本身项目实践，试图总结出一个通用的，可落地的方案。
基本思路
用户仅登录一次，用户改变密码，则废除token，重新登录
1.0实现
1.登录成功，返回access_token和refresh_token，客户端缓存此两种token2.使用access_token请求接口资源，成功则调用成功；如果token超时，客户端携带refresh_token调用中间件接口获取新的access_token3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，客户端收到该状态后，跳转到登录页；如未过期，生成新的access_token和refresh_token并返回给客户端（如有可能，让旧的refresh_token失效），客户端携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(使access_token和refresh_token失效)，同时清空客户端的access_token和refresh_toke。
后端表id user_id client_id client_secret refresh_token expire_in create_date del_flag
2.0实现
场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都能删除)，返回后，客户端缓存此两种token2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的access_token3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给客户端，客户端接着携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（废除）)，同时清空客户端侧的access_token和refresh_toke。5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动1.登录2.登录拦截器3.增加刷新access_token接口4.退出登录5.修改密码
3.0实现
场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token），设置access_token过期时间为7天，保证最终所有token都能删除)，返回后，客户端缓存此token
2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录2.登录拦截器3.退出登录4.修改密码
1.3 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为 "user_id:access_token",value为access_token（根据用户id，可以人工废除指定用户全部token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此access_token；
2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
1.3 变动
1.登录2.登录拦截器3.退出登录4.修改密码
2.0 场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓
存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全
部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都
能删除)，返回后，客户端缓存此两种token
2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果
token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的
access_token
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；
如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给
客户端，客户端接着携带新的access_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（
废除）)，同时清空客户端侧的access_token和refresh_toke。
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（
拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动
1.登录
2.登录拦截器
3.增加刷新access_token接口
4.退出登录
5.修改密码
3.0 场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为
access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以
根据sub-key,废除部分设备的token。），设置access_token过期时间为1个月，保证最终所有token都能删
除)，返回后，客户端缓存此token
2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果
token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
4.0 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为
"user_id:access_token" + 用户id,value为access_token（根据用户id，可以人工废除指定用户全部
token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此
access_token；
2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果
token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
4.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
最终实现
后端
