A JWT frissítési token kezelésének megoldása szögben a HttpInterceptor segítségével

Zökkenőmentes JWT-frissítés biztosítása a szögelfogókban

A biztonságos felhasználói munkamenetekkel rendelkező webalkalmazásokban a rövid élettartamú JWT-tokenek hatékony kezelése kulcsfontosságú a zavartalan felhasználói élmény érdekében. Amikor a tokenek lejárnak, a felhasználók gyakran találkoznak olyan problémákkal, mint például az újbóli bejelentkezés kényszerítése, ami frusztráló lehet, és megzavarhatja a felhasználói elköteleződést. Ennek megoldására a fejlesztők általában automatikus tokenfrissítést alkalmaznak egy Angular interceptor segítségével a lejárt munkamenetek kezelésére. 🕰️

Ez a megközelítés magában foglalja a HTTP kérések elfogását, a 401-es hibák (jogosulatlan kérések) elkapását, majd egy frissítési folyamat meghívását egy új token beszerzéséhez. Problémák adódhatnak azonban annak biztosításában, hogy a frissített tokent vagy cookie-t alkalmazzák az újrapróbált kérésekre. Ha az új token nem terjed megfelelően, előfordulhat, hogy az újrapróbálkozás sikertelen lesz, így a felhasználók ugyanazt az engedélyezési hibát okozzák, és potenciálisan megzavarhatják az alkalmazások munkafolyamatait.

Ebben az útmutatóban ennek az elfogó mintának gyakorlati megvalósítását mutatjuk be. Megvizsgáljuk, hogyan lehet elkapni a hibákat, frissíteni a tokeneket, és megbizonyosodni arról, hogy a kérések érvényes jogosultsággal próbálkoznak újra. Ez a megközelítés minimálisra csökkenti a megszakításokat, miközben Ön irányíthatja a munkamenet-megújítási folyamatot.

A végére betekintést nyerhet a gyakori buktatók megoldásába, például a HttpOnly cookie-k kezelésébe és a frissítési szekvenciák kezelésébe nagy mennyiségű kérés esetén. Ez a módszer biztosítja, hogy az alkalmazás biztonságos, zökkenőmentes felhasználói munkamenetet tartson fenn állandó bejelentkezés nélkül. 🔒

Megbízható JWT-hitelesítés biztosítása szögelfogókkal

A fenti példában az elfogót úgy tervezték, hogy automatikusan frissítsen egy rövid élettartamú JWT tokent, amikor 401-es hiba történik. Ez a fajta beállítás elengedhetetlen az érzékeny adatokat tartalmazó alkalmazásokban, ahol a munkamenet biztonságának fenntartása kritikus fontosságú, de a felhasználói élményt nem szabad megszakítani. Az elfogó elkapja a 401-es (jogosulatlan) hibát, és frissítési jogkivonat kérést kezdeményez a munkamenet megújításához anélkül, hogy a felhasználónak újbóli hitelesítésre lenne szüksége. Ezt a folyamatot a catchError függvény indítja el, amely lehetővé teszi a hibakezelést egy megfigyelhető folyamaton belül. Itt minden HTTP hiba, különösen a 401, azt jelzi, hogy a token valószínűleg lejárt, és elindítja a frissítési folyamatot.

A switchMap funkció egy másik alapvető elem itt; új megfigyelhető adatfolyamot hoz létre a frissített kéréshez, lecserélve a régi megfigyelhetőt anélkül, hogy megszakítaná a teljes folyamot. Frissítés után újra megpróbálja az eredeti kérést, biztosítva, hogy az új token alkalmazásra kerüljön. A régi megfigyelhetőről egy újra váltva az elfogó zökkenőmentesen, blokkolásmentesen tudja végrehajtani a token megújítást. Ez a technika különösen értékes, ha valós idejű alkalmazásokkal dolgozik, mivel csökkenti a felhasználói interakciók megszakításait, miközben továbbra is fenntartja a biztonságos hitelesítést. Például egy biztonságos pénzügyi irányítópulton böngésző felhasználó nem kerül átirányításra vagy szükségtelenül kijelentkezésre; ehelyett az új tokent beszerzi és alkalmazza a háttérben. 🔄

Ezenkívül a BehaviorSubject kulcsfontosságú szerepet játszik a frissítési folyamat állapotának kezelésében. Ez az RxJS segédprogram meg tudja őrizni az utoljára kibocsátott értéket, ami különösen akkor hasznos, ha több kérés egyidejűleg 401-es hibát észlel. Ahelyett, hogy több frissítést indítana el, az elfogó csak egy token frissítést kezdeményez, és az összes többi kérés sorba kerül, hogy erre az egyetlen jogkivonat megújítására várjon. A BehaviorSubject és a switchMap használata segít abban, hogy ha egy kérés elindítja a frissítést, az összes többi, az új tokent igénylő kérés a frissített hitelesítő adatokat használja anélkül, hogy ismételt frissítési hívást okozna. Ez a funkció rendkívül hasznos olyan esetekben, amikor a felhasználóknak több nyitott lapja van, vagy az alkalmazás több egyidejű hálózati hívást kezel, így erőforrásokat takarít meg, és elkerüli a túlzott szerverterhelést.

Ennek az elfogó logikának a tesztelése elengedhetetlen annak biztosításához is, hogy különböző forgatókönyvek szerint működjön, ezért a HttpTestingController alkalmazást is tartalmazzuk. Ez az Angular tesztelőeszköz lehetővé teszi a HTTP-válaszok szimulálását és tesztelését, például a 401 Jogosulatlan állapotot, ellenőrzött környezetben. A HttpTestingController által biztosított flush módszerrel a fejlesztők szimulálhatják a valós hibareakciókat, és ellenőrizhetik, hogy az elfogó a várt módon működik-e. Ez a tesztelési megközelítés lehetővé teszi annak finomítását, hogy a frissítési logika milyen jól kezeli a különböző eseteket az alkalmazás üzembe helyezése előtt. Ezekkel a módszerekkel az elfogó nemcsak biztonságosan megőrzi a munkamenetet, hanem zökkenőmentesebb, stabilabb élményt is nyújt az alkalmazásban navigáló felhasználók számára. 👩‍💻

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

A JWT token frissítési stratégiáinak bővítése szögelfogókkal

Az Angular használatának kritikus szempontja JWT token elfogó A biztonságos alkalmazásokhoz hatékonyan kezeli a hitelesítés és a munkamenet lejáratának kezelésének bonyolultságát. A 401-es hibák puszta elkapásán és a tokenek frissítésén túl elengedhetetlen, hogy gondoljunk a többkérés-kezelésre és a tokenfrissítések optimalizálására. Ha egyszerre több kérelem is 401-es hibába ütközik, egy sor vagy zárolási mechanizmus megvalósítása rendkívül hasznos lehet annak biztosítására, hogy egyszerre csak egy token frissítés történjen. Ez a megközelítés megakadályozza a szükségtelen API-hívásokat és csökkenti a terhelést, különösen a nagy forgalmú alkalmazásokban, miközben lehetővé teszi az összes sorba állított kérés folytatását a frissítés után.

Az Angular elfogói lehetővé teszik a token tárolásának és visszakeresésének egyszerűsítését is. Ahelyett, hogy a tokeneket a helyi tárolóban kódolnák, a legjobb az Angular-t használni HttpOnly cookie-k és CSRF védelem a biztonság fokozása érdekében. A HttpOnly cookie-kkal a JWT nem érhető el vagy nem manipulálható a JavaScript segítségével, ami jelentősen javítja a biztonságot, de új kihívást jelent: biztosítja, hogy a kérések automatikusan felvegyék a frissített cookie-t. Angular beépített withCredentials opció egy megoldás, amely utasítja a böngészőt, hogy minden kérésnél tartalmazza ezeket a sütiket.

Éles környezetben célszerű teljesítményteszteket futtatni arra vonatkozóan, hogy az alkalmazás hogyan viselkedik terhelés alatt a jogkivonat frissítésével. A tesztelési beállítások nagy kérésmennyiséget szimulálhatnak, biztosítva, hogy az elfogó logikája hatékonyan skálázódik. A gyakorlatban ez a beállítás minimálisra csökkenti annak kockázatát, hogy a tokenekkel kapcsolatos hibák befolyásolják a felhasználói élményt. Az elfogó stratégia, ha megfelelő cookie-kezeléssel és teszteléssel párosul, segít egy zökkenőmentes, felhasználóbarát és biztonságos alkalmazás fenntartásában – akár kritikus pénzügyi adatokat kezel, akár egy közösségi platform felhasználói munkameneteit. 🌐🔐