JWT Refresh Token tvarkymo kampinis sprendimas naudojant HttpInterceptor

Sklandaus JWT atnaujinimo užtikrinimas kampiniuose gaudytuvuose

Žiniatinklio programoje su saugiomis naudotojų sesijomis efektyvus trumpalaikių JWT prieigos raktų valdymas yra labai svarbus norint užtikrinti nepertraukiamą vartotojo patirtį. Pasibaigus žetonų galiojimo laikui, vartotojai dažnai susiduria su tokiomis problemomis kaip priverstinis prisijungimas iš naujo, o tai gali erzinti ir sutrikdyti vartotojų įsitraukimą. Kad tai išspręstų, kūrėjai dažniausiai taiko automatinį prieigos rakto atnaujinimą naudodami kampinį perėmėją, skirtą tvarkyti pasibaigusio galiojimo seansus. 🕰️

Šis metodas apima HTTP užklausų perėmimą, 401 klaidų (neteisėtų užklausų) gaudymą ir atnaujinimo procesą, kad gautų naują prieigos raktą. Tačiau gali kilti problemų užtikrinant, kad atnaujintas prieigos raktas arba slapukas būtų pritaikytas pakartotinai bandomoms užklausoms. Jei naujas prieigos raktas netinkamai platinamas, pakartotinis bandymas gali nepavykti, todėl naudotojai gali patirti tą pačią prieigos teisės klaidą ir gali sutrikdyti programos darbo eigą.

Šiame vadove apžvelgsime praktinį šio perėmėjo modelio įgyvendinimą. Pažiūrėsime, kaip pastebėti klaidas, atnaujinti prieigos raktus ir patvirtinti, kad užklausos bus bandomos iš naujo su galiojančiu įgaliojimu. Šis metodas sumažina pertraukimus ir suteikia jums galimybę valdyti seanso atnaujinimo procesą.

Pabaigoje įgausite įžvalgų, kaip išspręsti dažniausiai pasitaikančias klaidas, pvz., HttpOnly slapukų tvarkymą ir atnaujinimo sekų tvarkymą esant dideliam užklausų kiekiui. Šis metodas užtikrina, kad jūsų programa gali palaikyti saugią, sklandžią vartotojo sesiją be nuolatinių prisijungimų. 🔒

Patikimo JWT autentifikavimo užtikrinimas naudojant kampinius gaudytuvus

Aukščiau pateiktame pavyzdyje perėmėjas sukurtas taip, kad automatiškai atnaujintų trumpalaikį JWT prieigos raktą, kai tik įvyksta 401 klaida. Tokia sąranka yra būtina programose su neskelbtinais duomenimis, kai seanso saugumas yra labai svarbus, tačiau naudotojo patirtis neturėtų būti nutraukta. Perėmėjas užfiksuoja 401 (neteisėta) klaidą ir inicijuoja atnaujinimo prieigos rakto užklausą, kad atnaujintų seansą, nereikalaujant vartotojo iš naujo autentifikuoti. Šį procesą suaktyvina funkcija catchError, kuri leidžia stebėti klaidas. Čia bet kokia HTTP klaida, ypač 401, signalizuoja, kad prieigos rakto galiojimo laikas greičiausiai baigėsi, ir pradeda atnaujinimo procesą.

Funkcija switchMap yra dar vienas pagrindinis elementas; jis sukuria naują stebimą srautą atnaujintai užklausai, pakeičiant seną stebimą neatšaukiant viso srauto. Atnaujinus, jis iš naujo bando vykdyti pradinę užklausą, užtikrindamas, kad būtų pritaikytas naujas prieigos raktas. Perjungęs iš seno stebimo į naują, perėmėjas gali sklandžiai, neblokuojančiai atlikti prieigos rakto atnaujinimą. Ši technika ypač vertinga dirbant su realaus laiko programomis, nes sumažina vartotojo sąveikos trukdžius ir išlaiko saugų autentifikavimą. Pavyzdžiui, saugioje finansinėje informacijos suvestinėje naršantis vartotojas nebūtų be reikalo peradresuojamas ar atsijungtas; vietoj to naujas prieigos raktas įgyjamas ir taikomas fone. 🔄

Be to, BehaviorSubject atlieka lemiamą vaidmenį valdant atnaujinimo proceso būseną. Ši RxJS programa gali išsaugoti paskutinę išsiųstą vertę, o tai ypač naudinga, kai keliose užklausose vienu metu atsiranda 401 klaida. Užuot suaktyvinęs kelis atnaujinimus, perėmėjas inicijuoja tik vieną prieigos rakto atnaujinimą, o visos kitos užklausos pateikiamos eilėje laukti šio vieno prieigos rakto atnaujinimo. BehaviorSubject naudojimas su switchMap padeda užtikrinti, kad jei viena užklausa suaktyvins atnaujinimą, visos kitos užklausos, kurioms reikalingas naujas prieigos raktas, naudos atnaujintus kredencialus ir nesukels pakartotinių atnaujinimo iškvietimų. Ši funkcija itin naudinga tais atvejais, kai vartotojai gali turėti kelis atidarytus skirtukus arba programėlė vienu metu valdo kelis tinklo skambučius, taip taupydama išteklius ir išvengdama per didelės serverio apkrovos.

Šios gaudyklės logikos išbandymas taip pat labai svarbus siekiant užtikrinti, kad jis veiktų pagal skirtingus scenarijus, todėl įtraukiame HttpTestingController. Šis kampinio testavimo įrankis leidžia mums imituoti ir išbandyti HTTP atsakymus, pvz., būseną 401 Neteisėta, kontroliuojamoje aplinkoje. Naudodami HttpTestingController pateiktą metodą flush, kūrėjai gali imituoti realaus pasaulio klaidų atsakymus ir patikrinti, ar perėmėjas veikia taip, kaip tikėtasi. Šis testavimo metodas leidžia patikslinti, kaip gerai atnaujinimo logika tvarko įvairius atvejus prieš diegiant programą. Naudodamas šiuos metodus, perėmėjas ne tik saugiai išsaugo seansą, bet ir užtikrina sklandesnę, stabilesnę programėlę naršančių naudotojų patirtį. 👩‍💻

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 žetonų atnaujinimo strategijų išplėtimas naudojant kampinius gaudytuvus

Svarbus kampinio naudojimo aspektas JWT žetonų perėmėjas saugioms programoms efektyviai tvarko autentifikavimo ir seanso pabaigos valdymo sudėtingumą. Svarbu ne tik užfiksuoti 401 klaidas ir atnaujinti prieigos raktus, bet ir pagalvoti apie kelių užklausų tvarkymą ir kaip optimizuoti prieigos raktų atnaujinimus. Kai keliose užklausose vienu metu susiduriama su 401 klaida, eilės arba užrakinimo mechanizmo įdiegimas gali būti labai naudingas siekiant užtikrinti, kad vienu metu būtų atnaujintas tik vienas prieigos raktas. Šis metodas apsaugo nuo nereikalingų API iškvietimų ir sumažina apkrovą, ypač didelio srauto programose, o po atnaujinimo leidžia tęsti visas eilėje esančias užklausas.

„Angular“ perimtuvai taip pat leidžia mums supaprastinti žetonų saugojimą ir gavimą. Vietinėje saugykloje geriau naudoti Angular's, o ne koduoti žetonus „HttpOnly“ slapukai ir CSRF apsauga, siekiant padidinti saugumą. Naudojant „HttpOnly“ slapukus, „JavaScript“ negali pasiekti JWT ar juo manipuliuoti, todėl saugumas labai pagerinamas, tačiau atsiranda naujas iššūkis: užtikrinti, kad užklausos automatiškai paimtų atnaujintą slapuką. Įmontuotas kampinis withCredentials parinktis yra sprendimas, nurodantis naršyklei įtraukti šiuos slapukus į kiekvieną užklausą.

Gamybinėje aplinkoje patartina atlikti našumo testus, siekiant nustatyti, kaip programa veikia esant apkrovai, atnaujinant prieigos raktą. Testavimo sąrankos gali imituoti didelius užklausų kiekius, užtikrinant, kad gaudyklės logika būtų efektyviai keičiama. Praktiškai ši sąranka sumažina su prieigos raktu susijusių klaidų, turinčių įtakos vartotojo patirčiai, riziką. Perėmimo strategija, kartu su tinkamu slapukų tvarkymu ir testavimu, padeda palaikyti sklandžią, patogią ir saugią taikomąją programą – nesvarbu, ar programa tvarko svarbius finansinius duomenis, ar socialinės platformos naudotojų seansus. 🌐🔐