JWT atsvaidzināšanas pilnvaru apstrādes atrisināšana leņķiskā režīmā, izmantojot HttpInterceptor

Nevainojama JWT atsvaidzināšana leņķiskajos pārtvērējos

Tīmekļa lietotnē ar drošām lietotāju sesijām efektīvai īslaicīgu JWT marķieru pārvaldībai ir izšķiroša nozīme nepārtrauktai lietotāja pieredzei. Kad marķieru derīguma termiņš beidzas, lietotāji bieži saskaras ar tādām problēmām kā piespiedu atkārtota pieteikšanās, kas var būt nomākta un traucēt lietotāju iesaistīšanos. Lai to novērstu, izstrādātāji parasti ievieš automātisku marķiera atsvaidzināšanu, izmantojot leņķisko pārtvērēju, lai apstrādātu sesijas, kurām beidzies derīguma termiņš. 🕰️

Šī pieeja ietver HTTP pieprasījumu pārtveršanu, 401 kļūdu (nesankcionētu pieprasījumu) uztveršanu un pēc tam atsvaidzināšanas procesa izsaukšanu, lai iegūtu jaunu pilnvaru. Tomēr var rasties problēmas, nodrošinot atjauninātā marķiera vai sīkfaila lietošanu atkārtoti izmēģinātajiem pieprasījumiem. Ja jaunais marķieris netiek izplatīts pareizi, atkārtots mēģinājums var neizdoties, atstājot lietotājiem tādu pašu autorizācijas kļūdu un, iespējams, traucējot lietotņu darbplūsmas.

Šajā rokasgrāmatā mēs apskatīsim šī pārtvērēja modeļa praktisko ieviešanu. Mēs apskatīsim, kā uztvert kļūdas, atsvaidzināt marķierus un apstiprināt, ka pieprasījumi tiek mēģināti atkārtoti ar derīgu autorizāciju. Šī pieeja samazina pārtraukumus, vienlaikus ļaujot jums kontrolēt sesijas atjaunošanas procesu.

Beigās jūs gūsit ieskatu par to, kā novērst bieži sastopamās nepilnības, piemēram, HttpOnly sīkfailu apstrādi un atsvaidzināšanas secību pārvaldību liela pieprasījumu apjoma gadījumā. Šī metode nodrošina, ka jūsu lietojumprogramma var uzturēt drošu, vienmērīgu lietotāja sesiju bez pastāvīgas pieteikšanās. 🔒

Uzticamas JWT autentifikācijas nodrošināšana ar leņķiskajiem pārtvērējiem

Iepriekš minētajā piemērā pārtvērējs ir paredzēts, lai automātiski atsvaidzinātu īslaicīgu JWT marķieri ikreiz, kad tiek konstatēta kļūda 401. Šāda veida iestatīšana ir būtiska lietojumprogrammās ar sensitīviem datiem, kur sesijas drošības uzturēšana ir ļoti svarīga, taču lietotāja pieredzi nevajadzētu pārtraukt. Pārtvērējs uztver kļūdu 401 (Neatļauta) un ierosina atsvaidzināšanas pilnvaras pieprasījumu, lai atjaunotu sesiju, neprasot lietotājam veikt atkārtotu autentifikāciju. Šo procesu aktivizē funkcija catchError, kas nodrošina kļūdu apstrādi novērojamā konveijerā. Šeit jebkura HTTP kļūda, īpaši 401, norāda, ka marķiera derīguma termiņš, visticamāk, ir beidzies, un tiek uzsākts atsvaidzināšanas process.

Funkcija switchMap ir vēl viens galvenais elements šeit; tas atsvaidzinātajam pieprasījumam izveido jaunu novērojamo straumi, aizstājot veco novērojamo, neatceļot visu plūsmu. Pēc atsvaidzināšanas tas atkārtoti izmēģina sākotnējo pieprasījumu, nodrošinot, ka tiek lietots jaunais marķieris. Pārslēdzoties no vecā novērojamā uz jaunu, pārtvērējs var veikt marķiera atjaunošanu nemanāmi, nebloķējot. Šis paņēmiens ir īpaši vērtīgs, strādājot ar reāllaika lietojumprogrammām, jo ​​tas samazina lietotāju mijiedarbības pārtraukumus, vienlaikus saglabājot drošu autentifikāciju. Piemēram, lietotājs, kas pārlūko drošu finanšu informācijas paneli, netiks novirzīts vai nevajadzīgi atteicies; tā vietā jaunais marķieris tiek iegūts un lietots fonā. 🔄

Turklāt BehaviorSubject ir izšķiroša nozīme, pārvaldot atsvaidzināšanas procesa stāvokli. Šī RxJS utilīta var saglabāt pēdējo emitēto vērtību, kas ir īpaši noderīgi, ja vairākos pieprasījumos vienlaikus tiek parādīta kļūda 401. Tā vietā, lai aktivizētu vairākas atsvaidzināšanas, pārtvērējs sāk tikai vienu marķiera atsvaidzināšanu, un visi pārējie pieprasījumi tiek ievietoti rindā, lai gaidītu šo vienu pilnvaru atjaunošanu. BehaviorSubject izmantošana kopā ar switchMap palīdz nodrošināt, ka, ja viens pieprasījums aktivizē atsvaidzināšanu, visi pārējie pieprasījumi, kam nepieciešams jaunais pilnvaras, izmantos atjauninātos akreditācijas datus, neizraisot atkārtotus atsvaidzināšanas zvanus. Šī funkcija ir ļoti noderīga gadījumos, kad lietotājiem var būt atvērtas vairākas cilnes vai lietotne pārvalda vairākus vienlaicīgus tīkla zvanus, tādējādi ietaupot resursus un izvairoties no pārmērīgas servera slodzes.

Šīs pārtvērēja loģikas pārbaude ir būtiska arī, lai nodrošinātu, ka tā darbojas dažādos scenārijos, tāpēc mēs iekļaujam HttpTestingController. Šis leņķiskās pārbaudes rīks ļauj mums modelēt un pārbaudīt HTTP atbildes, piemēram, statusu 401 Neautorizēts, kontrolētā vidē. Izmantojot flush, HttpTestingController nodrošināto metodi, izstrādātāji var simulēt reālās pasaules kļūdu atbildes un pārbaudīt, vai pārtvērējs darbojas, kā paredzēts. Šī testēšanas pieeja ļauj mums precizēt, cik labi atsvaidzināšanas loģika apstrādā dažādus gadījumus pirms lietotnes izvietošanas. Izmantojot šīs metodes, pārtvērējs ne tikai droši saglabā sesiju, bet arī nodrošina vienmērīgāku un stabilāku pieredzi lietotājiem, kuri pārvietojas lietotnē. 👩‍💻

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

JWT marķiera atsvaidzināšanas stratēģiju paplašināšana ar leņķiskajiem pārtvērējiem

Angular izmantošanas kritiskais aspekts JWT marķiera pārtvērējs drošām lietojumprogrammām efektīvi tiek galā ar autentifikācijas un sesijas beigu pārvaldīšanas sarežģītību. Papildus tikai 401 kļūdu uztveršanai un marķieru atsvaidzināšanai ir svarīgi padomāt par vairāku pieprasījumu apstrādi un to, kā optimizēt marķiera atsvaidzināšanu. Ja vairākos pieprasījumos vienlaikus tiek konstatēta kļūda 401, rindas vai bloķēšanas mehānisma ieviešana var būt ļoti noderīga, lai nodrošinātu, ka vienlaikus tiek atsvaidzināts tikai viens marķieris. Šī pieeja novērš nevajadzīgus API izsaukumus un samazina slodzi, jo īpaši lietojumprogrammās ar lielu trafiku, vienlaikus ļaujot pēc atsvaidzināšanas turpināt visus rindā esošos pieprasījumus.

Angular pārtvērēji ļauj mums arī racionalizēt to, kā mēs rīkojamies ar marķieru glabāšanu un izguvi. Tā vietā, lai kodētu marķierus vietējā krātuvē, vislabāk ir izmantot Angular's HttpOnly sīkfaili un CSRF aizsardzība, lai uzlabotu drošību. Izmantojot HttpOnly sīkfailus, JWT nevar piekļūt vai manipulēt ar JavaScript, ievērojami uzlabojot drošību, bet pievienojot jaunu izaicinājumu: nodrošināt, ka pieprasījumi automātiski uztver atsvaidzināto sīkfailu. Angular ir iebūvēts withCredentials opcija ir risinājums, norādot pārlūkprogrammai iekļaut šos sīkfailus katrā pieprasījumā.

Ražošanas vidē ir ieteicams palaist veiktspējas testus, lai noskaidrotu, kā lietojumprogramma darbojas slodzes laikā ar pilnvaru atsvaidzināšanu. Testēšanas iestatījumi var simulēt lielu pieprasījumu apjomu, nodrošinot pārtvērēja loģikas efektīvu mērogošanu. Praksē šī iestatīšana samazina ar pilnvaru saistītu kļūdu risku, kas ietekmē lietotāja pieredzi. Pārtvērēja stratēģija, kas apvienota ar pareizu sīkfailu apstrādi un testēšanu, palīdz uzturēt netraucētu, lietotājam draudzīgu un drošu lietojumprogrammu neatkarīgi no tā, vai lietotne pārvalda kritiskos finanšu datus vai sociālās platformas lietotāju sesijas. 🌐🔐