
在现代Web应用中,API请求的认证通常依赖于令牌(如JWT)。当客户端的令牌过期或无效时,服务器会返回401(Unauthorized)状态码。为了提供无缝的用户体验,前端应用通常会实现一个“响应拦截器”(response-interceptor)来捕获401错误,自动刷新令牌,并使用新令牌重试失败的请求。
然而,当多个并发请求同时遇到401错误时,如果不加以处理,可能会导致:
理想的解决方案是,当多个请求同时收到401时,只发起一次令牌刷新,并且所有等待的请求都共享这个刷新过程,并在新令牌可用后重试。
为了解决上述问题,一种常见的策略是使用一个类字段(如awaitingPromise)来存储正在进行的令牌刷新Promise。当第一个请求遇到401并开始刷新令牌时,它会将刷新操作的Promise赋值给awaitingPromise。后续的并发请求如果也遇到401,则会等待awaitingPromise解析,获取新令牌,然后重试。
立即学习“Java免费学习笔记(深入)”;
以下是一个简化后的初始实现示例:
export class TokenFlushInterceptor {
private awaitingPromise: Promise<string> | null = null; // 存储刷新令牌的Promise
private async retry(response: Response, requestOptions: RequestInit, token: string): Promise<Response> {
// 使用新令牌重试原请求
return fetch(response.url, {
...requestOptions,
headers: {
...requestOptions!.headers,
Authorization: `Bearer ${token}`,
},
});
}
public async intercept(response: Response, requestOptions?: RequestInit): Promise<Response> {
if (AUTH_RESPONSE_CODES.UNAUTHORIZED === response.status) {
if (this.awaitingPromise) {
// 如果已有刷新操作在进行,则等待其完成
const newToken = await this.awaitingPromise;
// 注意:这里原代码有将 awaitingPromise 置为 null 的操作,这可能导致问题
// this.awaitingPromise = null; // 潜在问题点
const retryRequest = await this.retry(response, requestOptions!, newToken);
// this.awaitingPromise = null; // 潜在问题点
return retryRequest;
}
// 如果没有刷新操作在进行,则发起新的刷新
const store = ReduxService.serverReduxStore; // 假设ReduxService可用
if (!store) {
return response; // 无法刷新,直接返回原响应
}
// 发起刷新令牌操作,并将其Promise保存
this.awaitingPromise = store.dispatch(flushToken) as Promise<string>;
const newToken = await this.awaitingPromise;
// 注意:这里原代码有将 awaitingPromise 置为 null 的操作
// this.awaitingPromise = null; // 潜在问题点
const retryRequest = await this.retry(response, requestOptions!, newToken);
// this.awaitingPromise = null; // 潜在问题点
return retryRequest;
}
return response;
}
}在上述代码中,this.awaitingPromise的意图是作为刷新令牌操作的“锁”。然而,原代码中多次将this.awaitingPromise设置为null的操作,引发了一个关键疑问:当一个请求(例如X请求)完成令牌刷新并设置this.awaitingPromise = null时,另一个同时等待的请求(例如Y请求)是否会因为this.awaitingPromise变为null而无法获取到新令牌?
要解答上述疑问,我们必须深入理解JavaScript的执行模型:
核心结论: 在JavaScript的单线程模型中,一旦代码进入一个同步执行块(例如一个if语句内部,直到遇到下一个await),该执行块中的变量值不会被“另一个线程”在中间意外修改。 具体到awaitingPromise的场景:
用户提出的疑问:“awaitingPromise仍持有flushToken来自X请求,我们继续执行,但在X请求上下文中我们已经将awaitingPromise设置为null。那么,我们会在下面的代码段中得到null吗?” 答案是:不会。因为await操作是针对Promise对象本身的引用,而不是变量名。一旦await开始,它就“锁定”了那个Promise对象,即使变量被重新赋值或置空,正在等待的Promise也不会改变。
虽然JavaScript的单线程特性解决了“awaitingPromise在等待过程中被null掉”的误解,但原代码中过早地将this.awaitingPromise = null;的操作仍然是不健壮的。它应该在令牌刷新Promise真正完成(无论是成功还是失败)并且所有依赖它的请求都已处理完毕后,才被清除。
以下是一个更健壮的实现策略:
// 定义一个常量用于认证响应码
const AUTH_RESPONSE_CODES = {
UNAUTHORIZED: 401,
};
// 假设 ReduxService 和 flushToken 是可用的
// 例如:
// import { store } from './redux/store'; // 假设 Redux store 实例
// const ReduxService = { serverReduxStore: store };
// const flushToken = () => { /* 实际的刷新令牌dispatch操作,返回一个Promise */ return Promise.resolve("new_jwt_token"); };
export class TokenFlushInterceptor {
private awaitingPromise: Promise<string> | null = null; // 存储刷新令牌的Promise
/**
* 重试原始请求,使用新的令牌
* @param response 原始的401响应
* @param requestOptions 原始请求的配置
* @param token 新的JWT令牌
* @returns 重试后的响应
*/
private async retry(response: Response, requestOptions: RequestInit, token: string): Promise<Response> {
const headers = {
...requestOptions?.headers,
Authorization: `Bearer ${token}`,
};
return fetch(response.url, {
...requestOptions,
headers,
});
}
/**
* 拦截器核心逻辑
* @param response 接收到的响应
* @param requestOptions 请求配置
* @returns 处理后的响应
*/
public async intercept(response: Response, requestOptions?: RequestInit): Promise<Response> {
// 如果不是401错误,则直接返回响应
if (AUTH_RESPONSE_CODES.UNAUTHORIZED !== response.status) {
return response;
}
let currentRefreshPromise: Promise<string>;
// 检查是否已经有令牌刷新操作在进行
if (this.awaitingPromise) {
// 如果有,则所有后续的401请求都等待同一个刷新Promise
currentRefreshPromise = this.awaitingPromise;
} else {
// 如果没有,则发起一个新的令牌刷新操作
const store = ReduxService.serverReduxStore;
if (!store) {
console.error("Redux store not available for token refresh.");
throw new Error("Failed to refresh token: Redux store not initialized.");
}
// 发起刷新令牌的dispatch,并将其Promise保存到 awaitingPromise
// 确保 flushToken 返回一个 Promise<string>
currentRefreshPromise = store.dispatch(flushToken) as Promise<string>;
this.awaitingPromise = currentRefreshPromise;
// 关键:在刷新Promise完成(无论成功或失败)后,清除 awaitingPromise
// 这样确保只有当所有刷新逻辑都完成后,才能发起新的刷新以上就是JavaScript异步请求中401错误与令牌刷新:并发处理策略与实践的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号