refresh token 的使用

还是验证失败了再用 refresh token 刷新 access token 呢

我们小程序定时刷新，web 端过期后再刷新

后端对于 token 过期返回约定的状态码，前端封装 request 请求工具类，对于 token 过期状态码，做一个 token 无感刷新，具体操作：用 refresh 刷新 token ，把 token 过期的这个请求和刷新过程中的新的请求放到待请求队列中，token 刷新完，把队列中的请求用新 token 去请求

@ZZ74
@2han9wen71an

验证失败再刷新的话，会不会有点影响体验呢。比如用户点击了保存失败了，需要再点一次？

@ghjh #4 刷新完 token 后前端再发一次保存接口

refresh 当然不用用户介入，监测到 access 过期了就去 server 拿一个新的，多几个请求稍微慢一点

@ghjh 当 access token 过期后，用户执行操作，我们会弹出一个窗口进行自动续期，续期通过后弹窗自动关闭，然后再次提交一下接口

@Blake2Wang 这种对异常工况的处理会不会变得复杂呢。
比如 refresh 失效，网络原因刷新请求没有过来等等

@2han9wen71an #7 同时有多个请求的 token 过期，也会用 refresh 多次刷新么。

@ghjh 二次封装 request ，这些逻辑写在通用的请求和响应拦截器中，我的博客很久没维护了，你直接搜索一下 token 无感刷新，看一下代码就懂了，随便找了一篇给你 https://blog.csdn.net/weixin_57909742/article/details/134310007

就用 3 楼的方法，如果懒得自己手撸维护请求队列，前端好像有个 alova 请求库，内置了无感刷新 token 的策略

@Blake2Wang #10
@iamobj 好的，感谢各位。我了解一下

过期了再重新请求 acess token ，不用维护 refresh token

refresh_token 是不应该由三方前端持有的，而是三方后端持有的吧

用 access token 请求。
长票短票都在 redis ？ 服务端自动刷新就行 ；