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

原副标题：PCB axios 圣夫龙同时实现采用者托柳创下 access_token

↓所推荐高度关注↓

译者：JackySummer

序言

前段时间做工程项目的这时候，牵涉到两个sizes登入，即是工程项目的登入网页，用的是子公司相连接的两个登入网页，在该网页标准化处置方法论。最后同时实现采用者只需登入一场，就能以登入状况出访子公司母公司的大部份中文网站。

sizes登入( Single Sign On ，全称 SSO），是现阶段较为盛行的民营企业销售业务资源整合的软件系统众所周知，用于数个应用领域控制系统间，采用者只须要登入一场就能出访大部份彼此间的应用领域控制系统。

当中责任编辑讲的是在登入后怎样管理工作 access_token 和 refresh_token ，主要就是PCB axios圣夫龙，在此记录。

市场需求

后置情景

步入该工程项目某一网页 http://xxxx.project.com/profile 须要登入，未登入就链接至SSO登入网络平台，这时的登入邮箱 url为 http://xxxxx.com/login?app_id=project_name_id&redirect_url=http://xxxx.project.com/profile ，当中 app_id 是前台这边签订合同表述好的， redirect_url 是获得成功许可后选定的反弹门牌号。

输出帐号密码且恰当后，就会链接回刚开始步入的网页，并在页面带两个模块 ?code=XXXXX ，即是 http://xxxx.project.com/profile?code=XXXXXX ，code的值是采用一场后即合宪，且10两分钟内已过期

{ verify_code: code } ，并且该api已经自带 app_id 和 app_secret 两个固定值模块，通过它去请求许可的api，请求获得成功后得到返回值 { access_token: “xxxxxxx”, refresh_token: “xxxxxxxx”, expires_in: xxxxxxxx } ，存下 access_token 和 refresh_token 到cookie中（localStorage也能），这时采用者就算登入获得成功了。

access_token 为标准JWT格式，是许可令牌，能理解是验证采用者身份的，是应用领域在调用api出访和修改采用者数据必须传入的模块（放在请求头headers里），2小时后已过期。也是说，做完前三步后，你能调用须要采用者登入才能采用的api；但是假如你什么都不操作，静静过去两个小时后，再去请求这些api，就会报 access_token 已过期，调用失败。

那么总不能2小时后就让采用者退出登入吧，解决方法是两小时后拿着已过期的 access_token 和 refresh_token （ refresh_token 已过期时间一般长一些，比如两个月或更长）去请求 /refresh api，返回结果为 { access_token: “xxxxx”, expires_in: xxxxx } ，换取新的 access_token ，新的 access_token 已过期时间也是2小时，并重新存到cookie，循环往复继续保持登入调用采用者api了。 refresh_token 在限定已过期时间内（比如一周或两个月等），下次就能继续换取新的 access_token ，但过了限定时间，就算真正意义已过期了，也就要重新输出帐号密码来登入了。

子公司中文网站登入已过期时间都只有两小时（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 是前台包办的并不须要前端处置。但是，后置情景在那了，市场需求都是基于该情景下的。

市场需求

两个请求时，如果判断 access_token 已经已过期，那么就先要去调用创下token接口拿到新的 access_token ，再重新发起采用者请求。

如果同时发起数个采用者请求，第两个采用者请求去调用创下token接口，当接口还没返回时，其余的采用者请求也依旧发起了创下token接口请求，就会导致数个请求，这些请求怎样处置，是我们责任编辑的内容了。

写在请求圣夫龙里，在请求前，先利用最初请求返回的字段 expires_in 字段来判断 access_token 是否已经已过期，若已已过期，则将请求挂起，先创下 access_token 后再继续请求。

优点：能节省http请求

缺点：因为采用了本地时间判断，若本地时间被篡改，有校验失败的风险

写在响应圣夫龙里，拦截返回后的数据。先发起采用者请求，如果接口返回 access_token 已过期，先创下 access_token ，再进行一场重试。

优点：无需判断时间

缺点：会消耗多一场http请求

在此我选择的是方案二。

同时实现

这里采用axios，当中做的是请求后拦截，所以用到的是axios的响应圣夫龙 axios.interceptors.response.use 方法

方法介绍

@utils/auth.js

constTOKEN_KEY = access_token

constREGRESH_TOKEN_KEY =refresh_token

exportconstgetToken = => Cookies.get(TOKEN_KEY)

exportconstsetToken = ( token, params = {}) => {

Cookies.set(TOKEN_KEY, token, params)

}

exportconstsetRefreshToken = ( token) => {

Cookies.set(REGRESH_TOKEN_KEY, token)

}

request.js

import{ getToken, setToken, getRefreshToken } from@utils/auth

// 创下 access_token 的接口

constrefreshToken = => {

returninstance.post( /auth/refresh, { refresh_token: getRefreshToken }, true)

}

// 创建 axios 实例

constinstance = axios.create({

baseURL: process.env.GATSBY_API_URL,

timeout: 30000,

headers: {

Content-Type: application/json,

}

})

instance.interceptors.response.use(response=> {

returnresponse

}, error => {

if(!error.response) {

returnPromise.reject(error)

}

// token 过期或合宪，返回 401 状况码，在此处置方法论

returnPromise.reject(error)

})

// 给请求头添加 access_token

constsetHeaderToken = ( isNeedToken) => {

constaccessToken = isNeedToken ? getToken : null

if(isNeedToken) { // api 请求须要携带 access_token

if(!accessToken) {

console.log( 不存在 access_token 则链接回登入页)

}

instance.defaults.headers.common.Authorization =`Bearer ${accessToken}`

}

}

// 有些 api 并不须要采用者许可采用，则不携带 access_token；默认不携带，须要传则设置第三个模块为 true

exportconstget= (url, params = {}, isNeedToken = false) => {

setHeaderToken(isNeedToken)

returninstance({

method:get,

url,

params,

})

}

exportconstpost = ( url, params = {}, isNeedToken = false) => {

setHeaderToken(isNeedToken)

returninstance({

method: post,

url,

data: params,

})

}

接下来改造 request.js中axios的响应圣夫龙

instance.interceptors.response.use(response=> {

returnresponse

}, error => {

if(!error.response) {

returnPromise.reject(error)

}

if(error.response.status === 401) {

const{ config } = error

returnrefreshToken.then( res=> {

const{ access_token } = res.data

setToken(access_token)

config.headers.Authorization = `Bearer ${access_token}`

returninstance(config)

}).catch( err=> {

console.log( 抱歉，您的登入状况已失效，请重新登入！)

returnPromise.reject(err)

})

}

returnPromise.reject(error)

})

签订合同返回401状况码表示 access_token 已过期或者合宪，如果采用者发起两个请求后返回结果是 access_token 已过期，则请求创下 access_token 的接口。请求获得成功则步入 then 里面，重置配置，并创下 access_token 并重新发起原来的请求。

但如果 refresh_token 也已过期了，则请求也是返回401。这时调试会发现函数进不到 refreshToken 的 catch 里面，那是因为 refreshToken 方法内部是也是用了同个 instance 实例，重复响应圣夫龙401的处置方法论，但该函数本身是创下 access_token ，故须要把该接口排除掉，即：

if( error.response. status=== 401&& ! error. config.url.includes( /auth/refresh)) {}

上述代码就已经同时实现了托柳创下 access_token 了，当 access_token 没已过期，正常返回；已过期时，则axios内部进行了一场创下token的操作，再重新发起原来的请求。

优化防止多次创下 token

如果token是已过期的，那请求创下 access_token 的接口返回也是有一定时间间隔，如果这时还有其他请求发过来，就会再执行一场创下 access_token 的接口，就会导致多次创下 access_token 。

因此，我们须要做两个判断，表述两个标记判断当前是否处于创下 access_token 的状况，如果处在创下状况则不再允许其他请求调用该接口。

letisRefreshing =false// 标记是否正在创下 token

instance.interceptors.response.use( response=> {

returnresponse

}, error => {

if(!error.response) {

returnPromise.reject(error)

}

if(error.response.status === 401&& !error.config.url.includes(/auth/refresh)) {

const{ config } = error

if(!isRefreshing) {

isRefreshing = true

returnrefreshToken.then(res=> {

const{ access_token } = res.data

setToken(access_token)

config.headers.Authorization =`Bearer ${access_token}`

returninstance(config)

}).catch( err=> {

console.log( 抱歉，您的登入状况已失效，请重新登入！)

returnPromise.reject(err)

}).finally( => {

isRefreshing = false

})

}

}

returnPromise.reject(error)

})

同时发起数个请求的处置

上面做法还不够，因为如果同时发起数个请求，在token已过期的情况，第两个请求步入创下token方法，则其他请求进去没有做任何方法论处置，单纯返回失败，最后只执行了第两个请求，这显然不合理。

比如同时发起三个请求，第两个请求步入创下token的流程，第二个和第三个请求须要存起来，等到token更新后再重新发起请求。

在此，我们表述两个数组 requests ，用来保存处于等待的请求，之后返回两个 Promise ，只要不调用 resolve 方法，该请求就会处于等待状况，则能知道其实数组存的是函数；等到token更新完毕，则通过数组循环执行函数，即逐个执行resolve重发请求。

letisRefreshing =false// 标记是否正在创下 token

letrequests = [] // 存储待重发请求的数组

instance.interceptors.response.use( response=> {

returnresponse

}, error => {

if(!error.response) {

returnPromise.reject(error)

}

if(error.response.status ===401&& !error.config.url.includes( /auth/refresh)) {

const{ config } = error

if(!isRefreshing) {

isRefreshing =true

returnrefreshToken.then( res=> {

const{ access_token } = res.data

setToken(access_token)

config.headers.Authorization = `Bearer ${access_token}`

// token 创下后将数组的方法重新执行

requests.forEach( ( cb) =>cb(access_token))

requests = [] // 重新请求完清空

returninstance(config)

}).catch( err=> {

console.log( 抱歉，您的登入状况已失效，请重新登入！)

returnPromise.reject(err)

}).finally( => {

isRefreshing = false

})

} else{

// 返回未执行 resolve 的 Promise

returnnewPromise( resolve=> {

// 用函数形式将 resolve 存入，等待创下后再执行

requests.push( token=> {

config.headers.Authorization =`Bearer ${token}`

resolve(instance(config))

})

})

}

}

returnPromise.reject(error)

})

最后 request.js 代码

importaxios fromaxios

import{ getToken, setToken, getRefreshToken } from@utils/auth

// 创下 access_token 的接口

constrefreshToken = => {

returninstance.post( /auth/refresh, { refresh_token: getRefreshToken }, true)

}

// 创建 axios 实例

constinstance = axios.create({

baseURL: process.env.GATSBY_API_URL,

timeout: 30000,

headers: {

Content-Type: application/json,

}

})

letisRefreshing = false// 标记是否正在创下 token

letrequests = [] // 存储待重发请求的数组

instance.interceptors.response.use( response=> {

returnresponse

}, error => {

if(!error.response) {

returnPromise.reject(error)

}

if(error.response.status === 401&& !error.config.url.includes( /auth/refresh)) {

const{ config } = error

if(!isRefreshing) {

isRefreshing = true

returnrefreshToken.then( res=> {

const{ access_token } = res.data

setToken(access_token)

config.headers.Authorization = `Bearer ${access_token}`

// token 创下后将数组的方法重新执行

requests.forEach( ( cb) => cb(access_token))

requests = [] // 重新请求完清空

returninstance(config)

}).catch( err=> {

console.log( 抱歉，您的登入状况已失效，请重新登入！)

returnPromise.reject(err)

}).finally( => {

isRefreshing =false

})

} else{

// 返回未执行 resolve 的 Promise

returnnewPromise( resolve=> {

// 用函数形式将 resolve 存入，等待刷新后再执行

requests.push( token=> {

config.headers.Authorization = `Bearer ${token}`

resolve(instance(config))

})

})

}

}

returnPromise.reject(error)

})

// 给请求头添加 access_token

constsetHeaderToken = ( isNeedToken) => {

constaccessToken = isNeedToken ? getToken :null

if(isNeedToken) { // api 请求须要携带 access_token

if(!accessToken) {

console.log( 不存在 access_token 则链接回登入页)

}

instance.defaults.headers.common.Authorization = `Bearer ${accessToken}`

}

}

// 有些 api 并不须要采用者许可采用，则无需携带 access_token；默认不携带，须要传则设置第三个模块为 true

exportconstget= (url, params = {}, isNeedToken =false) => {

setHeaderToken(isNeedToken)

returninstance({

method: get,

url,

params,

})

}

exportconstpost = ( url, params = {}, isNeedToken = false) => {

setHeaderToken(isNeedToken)

returninstance({

method: post,

url,

data: params,

})

}

参考文章：

juejin.cn/post/6844903925078818829

– EOF –

点击副标题可链接

1、 Vue2 到 Vue3，重学这 5 个常用的 API

2、 低代码都做了什么？怎么同时实现 Low-Code？

3、 中高级前端工程师都须要熟悉的技能–前端缓存

↓所推荐高度关注↓

「大前端技术之路」分享 Web前端，Node.js、React Native等大前端技术栈精选

点赞和在看是最大的支持❤️