Rezolvarea procesării JWT Refresh Token în Angular cu HttpInterceptor

Asigurarea reîmprospătării JWT fără întreruperi în interceptoarele unghiulare

Într-o aplicație web cu sesiuni de utilizator securizate, gestionarea eficientă a token-urilor JWT de scurtă durată este crucială pentru o experiență neîntreruptă a utilizatorului. Când token-urile expiră, utilizatorii întâmpină adesea probleme, cum ar fi obligați să se reconectați, ceea ce poate fi frustrant și poate perturba implicarea utilizatorului. Pentru a rezolva acest lucru, dezvoltatorii implementează în mod obișnuit reîmprospătarea automată a simbolurilor folosind un interceptor Angular pentru a gestiona sesiunile expirate. 🕰️

Această abordare implică interceptarea solicitărilor HTTP, prinderea erori 401 (cereri neautorizate) și apoi invocarea unui proces de reîmprospătare pentru a obține un nou token. Cu toate acestea, pot apărea probleme în asigurarea că jetonul sau cookie-ul actualizat este aplicat solicitărilor reîncercate. Dacă noul token nu se propagă corect, reîncercarea poate eșua, lăsând utilizatorii cu aceeași eroare de autorizare și perturbând posibil fluxurile de lucru ale aplicației.

În acest ghid, vom parcurge o implementare practică a acestui model de interceptor. Vom analiza cum să detectăm erori, să reîmprospătăm tokenurile și să confirmăm că solicitările reîncercă cu autorizare validă. Această abordare minimizează întreruperile, oferindu-vă în același timp control asupra procesului de reînnoire a sesiunii.

Până la sfârșit, veți obține informații despre cum să abordați capcanele obișnuite, cum ar fi gestionarea cookie-urilor numai HTTP și gestionarea secvențelor de reîmprospătare în timpul unor volume mari de solicitări. Această metodă asigură că aplicația dvs. poate menține o sesiune de utilizator sigură, fără autentificare constantă. 🔒

Asigurarea autentificării fiabile JWT cu interceptoare unghiulare

În exemplul de mai sus, interceptorul este proiectat pentru a reîmprospăta automat un token JWT de scurtă durată ori de câte ori se întâlnește o eroare 401. Acest tip de configurare este esențial în aplicațiile cu date sensibile, unde menținerea securității sesiunii este critică, dar experiența utilizatorului nu ar trebui întreruptă. Interceptorul detectează eroarea 401 (Neautorizată) și inițiază o solicitare de reîmprospătare a simbolului pentru a reînnoi sesiunea fără a solicita utilizatorului să se autentifice din nou. Acest proces este declanșat de funcția catchError, care permite gestionarea erorilor într-o conductă observabilă. Aici, orice eroare HTTP, în special un 401, semnalează că simbolul probabil a expirat și inițiază procesul de reîmprospătare.

Funcția switchMap este un alt element de bază aici; creează un nou flux observabil pentru cererea reîmprospătată, înlocuind vechiul observabil fără a anula întregul flux. După reîmprospătare, reîncearcă solicitarea inițială, asigurându-se că noul token este aplicat. Trecând de la vechiul observabil la unul nou, interceptorul poate efectua reînnoirea simbolului într-o manieră fără întreruperi, fără blocare. Această tehnică este deosebit de valoroasă atunci când lucrați cu aplicații în timp real, deoarece reduce întreruperile interacțiunilor utilizatorului, menținând în același timp autentificarea securizată. De exemplu, un utilizator care navighează într-un tablou de bord financiar securizat nu va fi redirecționat sau deconectat în mod inutil; în schimb, noul token este achiziționat și aplicat în fundal. 🔄

În plus, BehaviorSubject joacă un rol crucial prin gestionarea stării procesului de reîmprospătare. Acest utilitar RxJS poate reține ultima valoare emisă, ceea ce este util în special atunci când cererile multiple întâmpină o eroare 401 în același timp. În loc să declanșeze mai multe reîmprospătări, interceptorul inițiază doar o reîmprospătare a simbolului, iar toate celelalte solicitări sunt puse în coadă pentru a aștepta reînnoirea acestui simbol unic. Utilizarea BehaviorSubject cu switchMap vă ajută să vă asigurați că, dacă o solicitare declanșează reîmprospătarea, toate celelalte solicitări care au nevoie de noul simbol vor folosi acreditările actualizate fără a provoca apeluri repetate de reîmprospătare. Această caracteristică este extrem de utilă în cazurile în care utilizatorii pot avea mai multe file deschise sau aplicația gestionează mai multe apeluri de rețea simultane, economisind astfel resurse și evitând încărcarea excesivă a serverului.

Testarea acestei logici de interceptor este, de asemenea, esențială pentru a ne asigura că funcționează în diferite scenarii, motiv pentru care includem HttpTestingController. Acest instrument de testare Angular ne permite să simulăm și să testăm răspunsurile HTTP, cum ar fi starea 401 Neautorizat, într-un mediu controlat. Folosind flush, o metodă oferită de HttpTestingController, dezvoltatorii pot simula răspunsurile de eroare din lumea reală și pot verifica dacă interceptorul se comportă conform așteptărilor. Această abordare de testare ne permite să rafinăm cât de bine logica de reîmprospătare gestionează diferite cazuri înainte de a implementa aplicația. Cu aceste metode, interceptorul nu numai că păstrează sesiunea în siguranță, dar oferă și o experiență mai uniformă și mai stabilă pentru utilizatorii care navighează în aplicație. 👩‍💻

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();
  });
});

Extinderea strategiilor de reîmprospătare a jetoanelor JWT cu interceptoare unghiulare

Un aspect critic al folosirii unui Angular Interceptor de jetoane JWT pentru aplicații securizate gestionează eficient complexitățile de gestionare a autentificării și expirării sesiunii. Dincolo de simpla captare a erorilor 401 și de reîmprospătare a jetoanelor, este esențial să ne gândim la gestionarea cererilor multiple și la modul de optimizare a reîmprospătărilor token-urilor. Când mai multe solicitări întâmpină o eroare 401 simultan, implementarea unei cozi de așteptare sau a unui mecanism de blocare poate fi extrem de utilă pentru a vă asigura că are loc o singură reîmprospătare a simbolului la un moment dat. Această abordare previne apelurile API inutile și reduce încărcarea, în special în aplicațiile cu trafic ridicat, permițând în același timp ca toate solicitările din coadă să continue după reîmprospătare.

Interceptorul unghiular ne permite, de asemenea, să simplificăm modul în care gestionăm stocarea și recuperarea jetoanelor. În loc să codificați jetoane în stocarea locală, cel mai bine este să utilizați Angular Cookie-uri HttpOnly și protecție CSRF pentru a spori securitatea. Cu modulele cookie HttpOnly, JWT nu poate fi accesat sau manipulat de JavaScript, îmbunătățind considerabil securitatea, dar adăugând o nouă provocare: asigurând că solicitările preiau cookie-ul reîmprospătat automat. Angular este încorporat withCredentials opțiunea este o soluție, solicitând browserului să includă aceste cookie-uri la fiecare solicitare.

Într-un mediu de producție, este recomandabil să rulați teste de performanță asupra modului în care aplicația se comportă sub încărcare cu reîmprospătări de simbol. Configurațiile de testare pot simula volume mari de cereri, asigurând că logica interceptorului se scalează eficient. În practică, această configurare minimizează riscul erorilor legate de simboluri care să afecteze experiența utilizatorului. Strategia de interceptor, atunci când este asociată cu gestionarea și testarea adecvată a cookie-urilor, ajută la menținerea unei aplicații fără probleme, ușor de utilizat și sigură, indiferent dacă aplicația gestionează date financiare critice sau sesiunile de utilizatori ale unei platforme sociale. 🌐🔐