本文详细介绍了如何利用axios拦截器机制，自动处理因访问令牌过期导致的403未授权错误。通过在http响应拦截器中捕获403状态码，触发令牌刷新流程，并使用新令牌重试原始请求，从而实现无缝的用户认证体验，避免用户频繁重新登录。
访问令牌自动刷新机制概述
在现代Web应用中，为了保障安全性，访问令牌（Access Token）通常具有较短的有效期（例如一小时）。当访问令牌过期后，客户端发送的API请求会收到服务器返回的401或403未授权错误。为了避免用户频繁地手动重新登录，我们需要一套机制来自动刷新过期的访问令牌。Axios的拦截器功能为实现这一机制提供了强大且灵活的解决方案。
使用Axios响应拦截器实现自动刷新
Axios拦截器允许我们在请求发送前或响应返回后对请求或响应进行统一处理。要实现访问令牌的自动刷新，我们主要利用响应拦截器来捕获API请求返回的错误。
核心思路
- 捕获403错误： 当API请求返回403（Unauthorized）状态码时，判断这是否是由于访问令牌过期引起的。
- 刷新令牌： 如果是令牌过期，则调用一个专门的函数来使用刷新令牌（Refresh Token）获取新的访问令牌。
- 更新令牌： 成功获取新令牌后，更新Axios的默认授权头部，并将其存储起来（例如在localStorage或Redux store中）。
- 重试请求： 使用新的访问令牌重新发送之前失败的原始请求。
- 防止循环： 引入一个标志位，确保只尝试一次令牌刷新和请求重试，避免无限循环。
示例代码与详细解析
以下是一个使用Axios响应拦截器实现自动刷新逻辑的示例：
import axios from 'axios';
// 创建一个Axios实例，便于管理其拦截器
const axiosApiInstance = axios.create({
baseURL: '/api', // 你的API基础URL
timeout: 10000,
});
// 存储刷新令牌的函数（需要你自行实现）
// 这个函数会使用refresh token向认证服务请求新的access token
async function refreshAccessToken() {
try {
// 假设你的认证服务提供一个 /auth/refresh 接口来刷新令牌
// 你需要从本地存储中获取refresh token，并发送请求
const refreshToken = localStorage.getItem('refreshToken'); // 或者从其他地方获取
const response = await axios.post('/auth/refresh', { refreshToken });
const { accessToken, newRefreshToken } = response.data;
// 更新本地存储的access token和refresh token
localStorage.setItem('accessToken', accessToken);
localStorage.setItem('refreshToken', newRefreshToken); // 如果refresh token也会更新
return accessToken;
} catch (error) {
console.error('Failed to refresh access token:', error);
// 刷新失败，通常意味着refresh token也过期或无效，需要用户重新登录
// 重定向到登录页
window.location.href = '/login';
return Promise.reject(error);
}
}
// 响应拦截器
axiosApiInstance.interceptors.response.use(
(response) => {
// 如果响应成功，直接返回
return response;
},
async function (error) {
const originalRequest = error.config;
// 检查错误响应状态码是否为403，并且该请求之前没有被重试过
// _retry 是一个自定义属性，用于标记请求是否已经尝试过刷新令牌并重试
if (error.response && error.response.status === 403 && !originalRequest._retry) {
originalRequest._retry = true; // 标记为已重试
try {
// 尝试刷新访问令牌
const newAccessToken = await refreshAccessToken();
// 更新Axios实例的默认授权头部，以便后续请求使用新令牌
axiosApiInstance.defaults.headers.common['Authorization'] = 'Bearer ' + newAccessToken;
// 同时更新原始请求的授权头部，以便重试该请求时使用新令牌
originalRequest.headers['Authorization'] = 'Bearer ' + newAccessToken;
// 使用更新后的授权头部，重新发送原始请求
return axiosApiInstance(originalRequest);
} catch (refreshError) {
// 如果令牌刷新失败，则拒绝该错误，并可能重定向到登录页
// refreshAccessToken函数内部已经处理了重定向，这里可以再次确认
return Promise.reject(refreshError);
}
}
// 对于其他类型的错误或已经重试过的403错误，直接拒绝
return Promise.reject(error);
}
);
export default axiosApiInstance;代码解析：
- axiosApiInstance： 创建一个独立的Axios实例，这样可以为特定的API请求配置拦截器，而不会影响全局的axios实例。
- refreshAccessToken()： 这是一个异步函数，负责与认证服务交互，使用存储的刷新令牌换取新的访问令牌。如果刷新失败（例如，刷新令牌也过期），它应该引导用户重新登录。
-
axiosApiInstance.interceptors.response.use(...)： 这是核心的响应拦截器。
- 成功回调： (response) => { return response; } 如果请求成功，直接返回响应。
-
失败回调： async function (error) { ... } 当请求失败时被调用。
- originalRequest = error.config： 获取导致错误的原始请求配置。
- error.response.status === 403 && !originalRequest._retry： 检查错误状态码是否为403，并且_retry标志未设置。_retry是一个自定义属性，用于防止在刷新令牌后再次收到403时陷入无限循环。
- originalRequest._retry = true： 设置_retry标志，表示该请求已尝试过刷新。
- await refreshAccessToken()： 调用刷新令牌函数。
-
更新授权头部：
- axiosApiInstance.defaults.headers.common['Authorization']：更新Axios实例的默认授权头部，确保后续所有新请求都使用新令牌。
- originalRequest.headers['Authorization']：更新原始请求的授权头部，这样当重新发送originalRequest时，它会带上新的令牌。
- return axiosApiInstance(originalRequest)： 重新发送原始请求。由于Axios请求返回一个Promise，这里通过返回一个新的Axios请求Promise，使得外部调用者能够像处理原始请求一样处理这个重试后的请求。
- 错误处理： 如果refreshAccessToken失败，捕获错误并拒绝，通常会导致用户被重定向到登录页面。
注意事项与最佳实践
- 刷新令牌的安全性： 刷新令牌通常具有更长的有效期，并且是获取新访问令牌的关键。应将其安全存储（例如，使用HTTP-only cookie或更安全的客户端存储机制）。
- 并发请求处理： 如果在令牌刷新过程中有多个请求同时收到403错误，可能会导致多次尝试刷新令牌。可以引入一个全局锁机制（例如，一个Promise），确保在刷新令牌时，所有其他待处理的请求都排队等待新令牌，而不是各自触发刷新。
- 登录页排除： 确保刷新令牌的逻辑不会应用于登录或注册等不需要授权的API请求，特别是获取刷新令牌本身的请求。
- 用户体验： 令牌刷新过程应该是无感知的。如果刷新失败，应清晰地引导用户重新登录，并提供友好的提示。
- 服务器端配合： 你的认证服务器需要提供一个专门的接口来处理刷新令牌的请求，并返回新的访问令牌和（可选的）新的刷新令牌。
- 错误类型区分： 并非所有的403错误都意味着令牌过期。有时403表示用户没有访问特定资源的权限。本教程中的实现假设403主要由令牌过期引起，但更健壮的系统可能需要服务器在错误响应中提供更具体的错误代码或消息来区分。
总结
通过巧妙地利用Axios的响应拦截器，我们可以构建一个健壮的访问令牌自动刷新机制。这不仅提升了用户体验，减少了不必要的登录操作，也增强了Web应用的安全性和可靠性。理解并正确实现这一机制，是开发高质量、高可用性Web应用的关键一环。
