Giải quyết việc xử lý mã thông báo làm mới JWT trong Angular bằng HttpInterceptor

Đảm bảo làm mới JWT liền mạch trong các thiết bị chặn góc

Trong ứng dụng web có phiên người dùng an toàn, việc quản lý mã thông báo JWT tồn tại trong thời gian ngắn một cách hiệu quả là rất quan trọng để đảm bảo trải nghiệm người dùng không bị gián đoạn. Khi mã thông báo hết hạn, người dùng thường gặp phải các vấn đề như buộc phải đăng nhập lại, điều này có thể gây khó chịu và làm gián đoạn sự tương tác của người dùng. Để giải quyết vấn đề này, các nhà phát triển thường triển khai làm mới mã thông báo tự động bằng cách sử dụng trình chặn chặn Angular để xử lý các phiên đã hết hạn. 🕰️

Cách tiếp cận này bao gồm việc chặn các yêu cầu HTTP, phát hiện lỗi 401 (yêu cầu trái phép) và sau đó gọi quy trình làm mới để nhận mã thông báo mới. Tuy nhiên, vấn đề có thể nảy sinh trong việc đảm bảo áp dụng mã thông báo hoặc cookie cập nhật cho các yêu cầu được thử lại. Nếu mã thông báo mới không được truyền chính xác thì quá trình thử lại có thể không thành công, khiến người dùng gặp lỗi ủy quyền tương tự và có khả năng làm gián đoạn quy trình làm việc của ứng dụng.

Trong hướng dẫn này, chúng ta sẽ hướng dẫn cách triển khai thực tế mẫu thiết bị chặn này. Chúng ta sẽ xem cách phát hiện lỗi, làm mới mã thông báo và xác nhận rằng các yêu cầu thử lại có ủy quyền hợp lệ. Cách tiếp cận này giảm thiểu sự gián đoạn trong khi cung cấp cho bạn quyền kiểm soát quá trình gia hạn phiên.

Cuối cùng, bạn sẽ hiểu rõ hơn về cách giải quyết các lỗi thường gặp, như xử lý cookie httpOnly và quản lý trình tự làm mới khi có khối lượng yêu cầu cao. Phương pháp này đảm bảo ứng dụng của bạn có thể duy trì phiên người dùng an toàn, mượt mà mà không cần đăng nhập liên tục. 🔒

Đảm bảo xác thực JWT đáng tin cậy với các thiết bị chặn góc

Trong ví dụ trên, bộ chặn được thiết kế để tự động làm mới mã thông báo JWT tồn tại trong thời gian ngắn bất cứ khi nào gặp phải lỗi 401. Kiểu thiết lập này rất cần thiết trong các ứng dụng có dữ liệu nhạy cảm, trong đó việc duy trì bảo mật phiên là rất quan trọng nhưng trải nghiệm người dùng sẽ không bị gián đoạn. Thiết bị chặn bắt lỗi 401 (Không được phép) và bắt đầu yêu cầu mã thông báo làm mới để gia hạn phiên mà không yêu cầu người dùng xác thực lại. Quá trình này được kích hoạt bởi hàm CatchError, cho phép xử lý lỗi trong một quy trình có thể quan sát được. Ở đây, bất kỳ lỗi HTTP nào, cụ thể là lỗi 401, đều báo hiệu rằng mã thông báo có thể đã hết hạn và bắt đầu quá trình làm mới.

Hàm switchMap là một thành phần cốt lõi khác ở đây; nó tạo ra một luồng có thể quan sát mới cho yêu cầu được làm mới, thay thế luồng có thể quan sát cũ mà không hủy toàn bộ luồng. Sau khi làm mới, nó thử lại yêu cầu ban đầu, đảm bảo rằng mã thông báo mới được áp dụng. Bằng cách chuyển từ cái cũ có thể quan sát được sang cái mới, thiết bị chặn có thể thực hiện việc gia hạn mã thông báo một cách liền mạch, không bị chặn. Kỹ thuật này đặc biệt có giá trị khi làm việc với các ứng dụng thời gian thực vì nó giúp giảm sự gián đoạn trong tương tác của người dùng trong khi vẫn duy trì xác thực an toàn. Ví dụ: người dùng duyệt bảng điều khiển tài chính được bảo mật sẽ không bị chuyển hướng hoặc đăng xuất một cách không cần thiết; thay vào đó, mã thông báo mới được lấy và áp dụng ở chế độ nền. 🔄

Ngoài ra, BehaviorSubject đóng vai trò quan trọng bằng cách quản lý trạng thái của quá trình làm mới. Tiện ích RxJS này có thể giữ lại giá trị được phát ra cuối cùng, điều này đặc biệt hữu ích khi nhiều yêu cầu gặp lỗi 401 cùng một lúc. Thay vì kích hoạt nhiều lần làm mới, thiết bị chặn chỉ bắt đầu làm mới một mã thông báo và tất cả các yêu cầu khác được xếp hàng đợi để chờ gia hạn một mã thông báo này. Việc sử dụng BehaviorSubject với switchMap giúp đảm bảo rằng nếu một yêu cầu kích hoạt quá trình làm mới thì tất cả các yêu cầu khác cần mã thông báo mới sẽ sử dụng thông tin xác thực đã cập nhật mà không gây ra các lệnh gọi làm mới lặp lại. Tính năng này cực kỳ hữu ích trong trường hợp người dùng có thể mở nhiều tab hoặc ứng dụng đang quản lý nhiều cuộc gọi mạng đồng thời, do đó tiết kiệm tài nguyên và tránh tải máy chủ quá mức.

Việc kiểm tra logic chặn này cũng rất cần thiết để đảm bảo rằng nó hoạt động trong các tình huống khác nhau, đó là lý do tại sao chúng tôi đưa vào HttpTestingController. Công cụ kiểm tra Angular này cho phép chúng tôi mô phỏng và kiểm tra các phản hồi HTTP, như trạng thái 401 Không được phép, trong môi trường được kiểm soát. Bằng cách sử dụng tính năng tuôn ra, một phương thức do HttpTestingController cung cấp, các nhà phát triển có thể mô phỏng các phản hồi lỗi trong thế giới thực và xác minh rằng thiết bị chặn hoạt động như mong đợi. Phương pháp thử nghiệm này cho phép chúng tôi tinh chỉnh mức độ làm mới xử lý các trường hợp khác nhau trước khi triển khai ứng dụng. Với các phương pháp này, thiết bị chặn không chỉ duy trì phiên an toàn mà còn mang lại trải nghiệm ổn định, liền mạch hơn cho người dùng điều hướng ứng dụng. 👩‍💻

import { Injectable } from '@angular/core';
import { HttpEvent, HttpInterceptor, HttpHandler, HttpRequest, HttpErrorResponse } from '@angular/common/http';
import { catchError, switchMap } from 'rxjs/operators';
import { Observable, throwError, BehaviorSubject } from 'rxjs';
import { AuthService } from './auth.service';
import { Router } from '@angular/router';
@Injectable()
export class JwtInterceptor implements HttpInterceptor {
  private refreshTokenInProgress$ = new BehaviorSubject<boolean>(false);
  constructor(private authService: AuthService, private router: Router) {}
  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    req = req.clone({ withCredentials: true });
    return next.handle(req).pipe(
      catchError((error: HttpErrorResponse) => {
        if (error.status === 401) {
          return this.handle401Error(req, next);
        }
        return throwError(() => error);
      })
    );
  }
  private handle401Error(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (!this.refreshTokenInProgress$.getValue()) {
      this.refreshTokenInProgress$.next(true);
      return this.authService.refreshToken().pipe(
        switchMap(() => {
          this.refreshTokenInProgress$.next(false);
          return next.handle(req.clone({ withCredentials: true }));
        }),
        catchError((error) => {
          this.refreshTokenInProgress$.next(false);
          this.authService.logout();
          this.router.navigate(['/login'], { queryParams: { returnUrl: req.url } });
          return throwError(() => error);
        })
      );
    }
    return this.refreshTokenInProgress$.pipe(
      switchMap(() => next.handle(req.clone({ withCredentials: true })))
    );
  }
}

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { JwtInterceptor } from './jwt.interceptor';
import { HTTP_INTERCEPTORS, HttpClient } from '@angular/common/http';
import { AuthService } from './auth.service';
describe('JwtInterceptor', () => {
  let httpMock: HttpTestingController;
  let authServiceSpy: jasmine.SpyObj<AuthService>;
  let httpClient: HttpClient;
  beforeEach(() => {
    authServiceSpy = jasmine.createSpyObj('AuthService', ['refreshToken', 'logout']);
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [
        JwtInterceptor,
        { provide: HTTP_INTERCEPTORS, useClass: JwtInterceptor, multi: true },
        { provide: AuthService, useValue: authServiceSpy }
      ]
    });
    httpMock = TestBed.inject(HttpTestingController);
    httpClient = TestBed.inject(HttpClient);
  });
  afterEach(() => {
    httpMock.verify();
  });
  it('should refresh token on 401 error and retry request', () => {
    authServiceSpy.refreshToken.and.returnValue(of(true));
    httpClient.get('/test').subscribe();
    const req = httpMock.expectOne('/test');
    req.flush(null, { status: 401, statusText: 'Unauthorized' });
    expect(authServiceSpy.refreshToken).toHaveBeenCalled();
  });
});

Mở rộng chiến lược làm mới mã thông báo JWT với các thiết bị chặn góc

Một khía cạnh quan trọng của việc sử dụng Angular Trình chặn mã thông báo JWT dành cho các ứng dụng bảo mật đang xử lý hiệu quả sự phức tạp của việc quản lý xác thực và hết hạn phiên. Ngoài việc chỉ phát hiện lỗi 401 và làm mới mã thông báo, điều cần thiết là phải suy nghĩ về việc xử lý nhiều yêu cầu và cách tối ưu hóa việc làm mới mã thông báo. Khi nhiều yêu cầu gặp phải lỗi 401 cùng một lúc, việc triển khai cơ chế xếp hàng hoặc khóa có thể cực kỳ hữu ích để đảm bảo chỉ xảy ra một lần làm mới mã thông báo tại một thời điểm. Cách tiếp cận này ngăn chặn các lệnh gọi API không cần thiết và giảm tải, đặc biệt là trong các ứng dụng có lưu lượng truy cập cao, đồng thời cho phép tất cả các yêu cầu xếp hàng đợi tiếp tục sau khi làm mới.

Các thiết bị chặn của Angular cũng cho phép chúng tôi hợp lý hóa cách chúng tôi xử lý việc lưu trữ và truy xuất mã thông báo. Thay vì mã hóa mã thông báo trong bộ nhớ cục bộ, tốt nhất nên sử dụng Angular HttpOnly cookie và bảo vệ CSRF để tăng cường bảo mật. Với cookie HttpOnly, JavaScript không thể truy cập hoặc thao tác JWT, cải thiện đáng kể tính bảo mật nhưng lại thêm một thách thức mới: đảm bảo rằng các yêu cầu tự động nhận cookie được làm mới. Tích hợp sẵn của Angular withCredentials tùy chọn là một giải pháp, hướng dẫn trình duyệt đưa các cookie này vào mỗi yêu cầu.

Trong môi trường sản xuất, bạn nên chạy thử nghiệm hiệu suất về cách ứng dụng hoạt động khi tải bằng cách làm mới mã thông báo. Thiết lập thử nghiệm có thể mô phỏng khối lượng yêu cầu cao, đảm bảo rằng logic của thiết bị chặn có quy mô hiệu quả. Trong thực tế, thiết lập này giảm thiểu rủi ro xảy ra lỗi liên quan đến mã thông báo ảnh hưởng đến trải nghiệm người dùng. Chiến lược chặn, khi kết hợp với việc kiểm tra và xử lý cookie thích hợp, sẽ giúp duy trì một ứng dụng liền mạch, thân thiện với người dùng và an toàn—cho dù ứng dụng đó quản lý dữ liệu tài chính quan trọng hay phiên người dùng của nền tảng xã hội. 🌐🔐