I encountered a problem a while ago. Sometimes when the online platform is in use, the user suddenly needs to log in, which will cause a very bad user experience, but there was no good idea at that time, so it was put on hold; through scattered Time to query information and think, finally solved this problem, and then share with you!

environment

Axios V1.3.2 is requested.
The platform adopts JWT(JSON Web Tokens)user login authentication.
(Expansion: JWT is an authentication mechanism that lets the background know that the request comes from a trusted client; for more detailed information, you can query relevant information yourself)

problem phenomenon

When online users are using it, occasionally they will suddenly jump to the login page and need to log in again.

reason

The sudden jump to the login page is due to the expiration of the current token, resulting in a request failure; the status code 401 returned by the failed request is processed in axiosthe response interception , and the failure is known at this time, so it jumps to the login page and allows the user to log in again .axiosInstance.interceptors.response.usetoken
The current logic of the platform is that within tokenthe unexpired period, users can log in to the platform and directly enter the home page without login operations; therefore, there is this phenomenon: when the user opens the platform, since the is not tokenexpired at this time, the user directly enters the home page and performs other operations. However, in the process of user operation, tokenit suddenly fails, and at this time there will be a sudden jump to the login page, which seriously affects the user experience!
( Note: At present, there are large data screens and some real-time data displays in online projects; therefore, there are situations where users stay on the large screen for a long time without performing operations and view real-time data )

entry point

How to update in a timely manner without the user noticing it token?
In tokenthe case of invalidation, there may be more than one error request; when the invalidation is tokenupdated, how to resend multiple failed requests?

Operating procedures

好了！经过了一番分析后，我们找到了问题的所在，并且确定了切入点；那么接下来让我们实操，将问题解决掉。
前要：
1、我们仅从前端的角度去处理。
2、后端提供了两个重要的参数：accessToken（用于请求头中，进行鉴权，存在有效期）；refreshToken（刷新令牌，用于更新过期的 accessToken，相对于 accessToken 而言，它的有效期更长）。

1、处理 axios 响应拦截

注：在我实际的项目中，accessToken 过期后端返回的 statusCode 值为 401，需要在axiosInstance.interceptors.response.use 的 error回调中进行逻辑处理。

// 响应拦截
axiosInstance.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    let {
      data, config
    } = error.response;
    return new Promise((resolve, reject) => {
      /**
       * 判断当前请求失败
       * 是否由 toekn 失效导致的
       */
      if (data.statusCode === 401) {
         /**
         * refreshToken 为封装的有关更新 token 的相关操作 
         */
        refreshToken(() => {
          resolve(axiosInstance(config));
        });
      } else {
        reject(error.response);
      }
    })
  }
)

我们通过判断statusCode来确定，是否当前请求失败是由token过期导致的；
使用 Promise 处理将失败的请求，将由于 token 过期导致的失败请求存储起来（存储的是请求回调函数，resolve 状态）。理由：后续我们更新了 token 后，可以将存储的失败请求重新发起，以此来达到用户无感的体验

补充：

现象：在我过了几天登录平台的时候发现，refreshToken过期了，但是没有跳转到登录界面原因：
1、当refreshToken过期失效后，后端返回的状态码也是 401
2、发起的更新token的请求采用的也是处理后的axios，因此响应失败的拦截，对更新请求同样适用。
问题：
这样会造成，当refreshToken过期后，会出现停留在首页，无法跳转到登录页面。
解决方法
针对这种现象，我们需要完善一下axios中响应拦截的逻辑。

axiosInstance.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    let {
      data, config
    } = error.response;
    return new Promise((resolve, reject) => {
      /**
       * 判断当前请求失败
       * 是否由 toekn 失效导致的
       */
      if (
        data.statusCode === 401 &&
        config.url !== '/api/token/refreshToken'
      ) {
        refreshToken(() => {
          resolve(axiosInstance(config));
        });
      } else if (
        data.statusCode === 401 &&
        config.url === '/api/token/refreshToken'
      ) {
        /**
         * 后端 更新 refreshToken 失效后
         * 返回的状态码， 401
         */
        window.location.href = `${HOME_PAGE}/login`;
      } else {
        reject(error.response);
      }
    })
  }
)

2、封装 refreshToken 逻辑

要点：

存储由于token过期导致的失败的请求。
更新本地以及axios中头部的token。
当 refreshToken 刷新令牌也过期后，让用户重新登录。

// 存储由于 token 过期导致 失败的请求
let expiredRequestArr: any[] = [];

/**
 * 存储当前因为 token 失效导致发送失败的请求
 */
const saveErrorRequest = (expiredRequest: () => any) => {
  expiredRequestArr.push(expiredRequest);
}

// 避免频繁发送更新 
let firstRequre = true;
/**
 * 利用 refreshToken 更新当前使用的 token
 */
const updateTokenByRefreshToken = () => {
  firstRequre = false;
  axiosInstance.post(
    '更新 token 的请求',
  ).then(res => {
    let {
      refreshToken, accessToken
    } = res.data;
    // 更新本地的token
    localStorage.setItem('accessToken', accessToken);
    // 更新请求头中的 token
    setAxiosHeader(accessToken);
    localStorage.setItem('refreshToken', refreshToken);

    /**
     * 当获取了最新的 refreshToken, accessToken 后
     * 重新发起之前失败的请求
     */
    expiredRequestArr.forEach(request => {
      request();
    })
    expiredRequestArr = [];
  }).catch(err => {
    console.log('刷新 token 失败err', err);
    /**
     * 此时 refreshToken 也已经失效了
     * 返回登录页，让用户重新进行登录操作
     */
    window.location.href = `${HOME_PAGE}/login`;
  })
}

/**
 * 更新当前已过期的 token
 * @param expiredRequest 回调函数，返回由token过期导致失败的请求
 */
export const refreshToken = (expiredRequest: () => any) => {
  saveErrorRequest(expiredRequest);
  if (firstRequre) {
    updateTokenByRefreshToken();
  }
}

总结

经过一波分析以及操作，我们最终实现了实际项目中的无感刷新token，最主要的是有效避免了：用户在平台操作过程中突然要退出登录的现象（尤其是当用户进行信息填写，突然要重新登录，之前填写的信息全部作废，是很容易让人发狂的）。
其实回顾一下，技术上并没有什么难点，只是思路上自己是否能够想通、自洽。人是一棵会思想的芦苇，我们要有自己的思想，面对问题，有自己的思考。
希望我们能在技术的路上走的越来越远，与君共勉！！！

How to realize the non-sensing refresh token in the front end of the project!