本文详细阐述了如何利用 %ignore_a_1% 拦截器实现 access token 的自动刷新机制。针对 access token 过期导致的 403 未授权错误，通过配置响应拦截器，在检测到特定错误码时，自动触发令牌刷新流程，更新授权头部并重试原请求，从而提升用户体验，避免频繁重新登录。
理解 Access Token 过期问题
在现代 Web 应用中，为了增强安全性，Access Token 通常会设置较短的有效期（例如一小时）。当 Access Token 过期后，客户端向受保护资源发起请求时，服务器会返回 401 Unauthorized 或 403 Forbidden 错误，导致用户需要重新登录才能继续操作，这严重影响了用户体验。为了解决这一问题，我们需要一种机制在 Access Token 过期时，能够静默地自动获取新的 Access Token。
Axios 拦截器：解决方案核心
Axios 作为流行的 HTTP 客户端库，提供了强大的拦截器（Interceptors）功能，允许我们在请求发送前或响应返回后进行处理。利用响应拦截器，我们可以捕获 HTTP 错误，并在 Access Token 过期时执行刷新操作。
实现自动刷新逻辑
实现 Access Token 自动刷新的核心在于配置 Axios 的响应拦截器。当一个 HTTP 请求返回错误时，拦截器会检查错误状态码。如果检测到 403 Unauthorized 错误，并且该请求之前没有被重试过，拦截器将尝试刷新 Access Token，然后用新的 Access Token 重新发起原始请求。
具体实现步骤如下：
捕获错误响应: 在 axiosApiInstance.interceptors.response.use 的第二个参数（错误处理函数）中捕获所有请求错误。判断错误类型: 检查 error.response.status 是否为 403。防止无限重试: 使用 originalRequest._retry 标志位确保每个失败的请求只重试一次，避免在刷新失败时陷入死循环。执行令牌刷新: 调用一个异步函数（例如 refreshAccessToken()）来获取新的 Access Token。这个函数通常会使用 Refresh Token 向认证服务器请求新的 Access Token 和 Refresh Token。更新授权头部: 成功获取新 Access Token 后，更新 Axios 实例的默认 Authorization 头部，确保后续请求使用新令牌。重试原始请求: 使用新的 Access Token 重新发起之前失败的 originalRequest。
以下是实现这一逻辑的示例代码：
import axios from 'axios';// 假设您有一个预配置的 Axios 实例const axiosApiInstance = axios.create({ baseURL: '/api', // 您的 API 基础路径 timeout: 10000, headers: { 'Content-Type': 'application/json', // 初始的 Authorization header 可以在登录时设置 }});// 模拟刷新 Access Token 的函数// 在实际应用中，此函数会使用 Refresh Token 调用认证服务接口async function refreshAccessToken() { console.log("尝试刷新 Access Token..."); // 假设这里调用了一个 API 来获取新的 Access Token // 例如：const response = await axios.post('/auth/refresh-token', { refreshToken: storedRefreshToken }); // const newAccessToken = response.data.accessToken; // 实际项目中，需要从本地存储获取 refreshToken，并更新本地存储的 accessToken // 模拟异步操作 return new Promise(resolve => { setTimeout(() => { const newAccessToken = 'new_access_token_' + Date.now(); console.log("Access Token 刷新成功:", newAccessToken); // 在这里您可能还需要更新本地存储的 refreshToken resolve(newAccessToken); }, 1500); });}// 响应拦截器axiosApiInstance.interceptors.response.use( (response) => { // 如果响应成功，直接返回 return response; }, async function (error) { const originalRequest = error.config; // 检查是否为 403 错误且未重试过 // error.response 存在且状态码为 403，并且 originalRequest._retry 为 false (未重试过) if (error.response && error.response.status === 403 && !originalRequest._retry) { originalRequest._retry = true; // 标记为已重试 try { // 尝试刷新 Access Token const newAccessToken = await refreshAccessToken(); // 更新 Axios 实例的默认授权头部，影响所有后续请求 axiosApiInstance.defaults.headers.common['Authorization'] = 'Bearer ' + newAccessToken; // 更新原始请求的授权头部，以便重新发送 originalRequest.headers['Authorization'] = 'Bearer ' + newAccessToken; // 重新发送原始请求 return axiosApiInstance(originalRequest); } catch (refreshError) { console.error("Access Token 刷新失败:", refreshError); // 如果刷新失败，或者 refreshAccessToken 函数内部决定重定向， // 则可以导向登录页面，并清除本地存储的令牌信息 // window.location.href = '/login?error=session_expired'; return Promise.reject(refreshError); // 拒绝Promise，将错误传递下去 } } // 对于其他错误或已重试的 403 错误，直接拒绝Promise return Promise.reject(error); });// 示例用法async function fetchData() { try { // 假设在某些情况下，需要手动设置 Authorization header，或者它已经在登录时设置 // axiosApiInstance.defaults.headers.common['Authorization'] = 'Bearer ' + 'expired_access_token'; const response = await axiosApiInstance.get('/protected-data'); console.log("获取受保护数据成功:", response.data); } catch (error) { console.error("获取受保护数据失败:", error.response ? error.response.data : error.message); }}// 模拟一个需要 Access Token 的请求// fetchData();
refreshAccessToken 函数的实现考量
refreshAccessToken 函数是整个自动刷新机制的关键。在实际应用中，它通常会执行以下操作：
获取 Refresh Token: 从本地存储（如 localStorage 或 sessionStorage）中获取存储的 Refresh Token。发送刷新请求: 向认证服务器的刷新令牌接口发送 POST 请求，携带 Refresh Token。处理响应:如果成功，服务器会返回新的 Access Token 和（可能）新的 Refresh Token。将这些新令牌更新到本地存储。如果失败（例如 Refresh Token 也过期或无效），则需要清除所有令牌，并将用户重定向到登录页面。返回新 Access Token: 将新获取的 Access Token 返回给拦截器。
注意事项与最佳实践
防止无限重试: originalRequest._retry 标志至关重要，它能有效避免在 Access Token 刷新失败时导致请求无限循环。Refresh Token 的安全性: Refresh Token 具有更长的有效期，因此需要妥善存储。建议使用 HttpOnly cookie 或其他安全机制，避免 JavaScript 直接访问。刷新失败处理: 如果 Refresh Token 也已过期或刷新请求本身失败，必须将用户重定向到登录页面，并清除所有本地存储的令牌信息，以确保安全性。并发请求处理: 在 Access Token 刷新过程中，如果同时有多个请求因 403 错误而触发刷新，可能会导致多次不必要的刷新请求。一种优化方式是，当第一个刷新请求发出后，后续的 403 错误请求可以暂停，等待第一个刷新请求完成后，再使用新的 Access Token 重新发送。这可以通过一个队列或 Promise 链来实现。用户体验: 自动刷新机制应尽可能对用户透明。只有在 Refresh Token 也失效时才提示用户重新登录。认证端点排除: 刷新令牌的请求（例如 /auth/refresh-token）本身不应该被拦截器处理，因为它不需要 Access Token。在拦截器中添加条件，排除这些特定端点，防止它们被误拦截。
总结
通过巧妙地利用 Axios 拦截器，我们可以构建一个健壮的 Access Token 自动刷新机制。这不仅解决了 Access Token 短有效期带来的用户体验问题，减少了用户频繁登录的困扰，也提升了应用程序的整体可用性和专业性。正确实现这一机制，包括考虑 Refresh Token 的安全性、刷新失败的优雅处理以及并发请求的优化，是构建现代安全 Web 应用的关键一环。
以上就是使用 Axios 拦截器实现 Access Token 自动刷新机制的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1529926.html
微信扫一扫 
支付宝扫一扫 
