封装 axios 拦截器实现用户无感刷新 access_token

网站建设4年前发布
44 0 0

20230306011944b9e016c963565c9b9708480f2d35d81927f640885,最近做项目的时候,涉及到一个单点登录,即是项目的登录页面,用的是公司共用的一个登录页面,在该页面统一处理逻辑。最终实现用户只需登录一次,就可以以登录状态访问公司旗下的所有网站。,其中本文讲的是在登录后如何管理access_token和refresh_token,主要就是封装 axios拦截器,在此记录。,2023030601173835f2d2a1674068b70cf38342987a7785c08080958,公司网站登录过期时间都只有两小时(token过期时间),但又想让一个月内经常活跃的用户不再次登录,于是才有这样需求,避免了用户再次输入账号密码登录。,为什么要专门用一个 refresh_token 去更新 access_token 呢?首先access_token会关联一定的用户权限,如果用户授权更改了,这个access_token也是需要被刷新以关联新的权限的,如果没有 refresh_token,也可以刷新 access_token,但每次刷新都要用户输入登录用户名与密码,多麻烦。有了 refresh_ token,可以减少这个麻烦,客户端直接用 refresh_token 去更新 access_token,无需用户进行额外的操作。,说了这么多,或许有人会吐槽,一个登录用access_token就行了还要加个refresh_token搞得这么麻烦,或者有的公司refresh_token是后台包办的并不需要前端处理。但是,前置场景在那了,需求都是基于该场景下的。,写在请求拦截器里,在请求前,先利用最初请求返回的字段expires_in字段来判断access_token是否已经过期,若已过期,则将请求挂起,先刷新access_token后再继续请求。,写在响应拦截器里,拦截返回后的数据。先发起用户请求,如果接口返回access_token过期,先刷新access_token,再进行一次重试。,在此我选择的是方案二。,这里使用axios,其中做的是请求后拦截,所以用到的是axios的响应拦截器axios.interceptors.response.use()方法,接下来改造 request.js中axios的响应拦截器。,约定返回401状态码表示access_token过期或者无效,如果用户发起一个请求后返回结果是access_token过期,则请求刷新access_token的接口。请求成功则进入then里面,重置配置,并刷新access_token并重新发起原来的请求。,但如果refresh_token也过期了,则请求也是返回401。此时调试会发现函数进不到refreshToken()的catch里面,那是因为refreshToken()方法内部是也是用了同个instance实例,重复响应拦截器401的处理逻辑,但该函数本身就是刷新access_token,故需要把该接口排除掉,即:,上述代码就已经实现了无感刷新access_token了,当access_token没过期,正常返回;过期时,则axios内部进行了一次刷新token的操作,再重新发起原来的请求。,如果token是过期的,那请求刷新access_token的接口返回也是有一定时间间隔,如果此时还有其他请求发过来,就会再执行一次刷新access_token的接口,就会导致多次刷新access_token。,因此,我们需要做一个判断,定义一个标记判断当前是否处于刷新access_token的状态,如果处在刷新状态则不再允许其他请求调用该接口。,上面做法还不够,因为如果同时发起多个请求,在token过期的情况,第一个请求进入刷新token方法,则其他请求进去没有做任何逻辑处理,单纯返回失败,最终只执行了第一个请求,这显然不合理。,比如同时发起三个请求,第一个请求进入刷新token的流程,第二个和第三个请求需要存起来,等到token更新后再重新发起请求。,在此,我们定义一个数组requests,用来保存处于等待的请求,之后返回一个Promise,只要不调用resolve方法,该请求就会处于等待状态,则可以知道其实数组存的是函数;等到token更新完毕,则通过数组循环执行函数,即逐个执行resolve重发请求。,最终 request.js 代码,参考文章:

© 版权声明

相关文章