PD-238 — Revue de Code¶

Résumé¶

Verdict : ⚠️ RÉSERVES

Controller thin/service fat bien respecté, responsabilité claire.
Guards enchaînés par endpoint (JWT + rate limit + reauth) conformes aux invariants clés.
Usage explicite de @UseFilters(MfaExceptionFilter) pour centraliser la gestion d’erreurs.
Nommage des routes/DTOs cohérent avec la spécification.

ID	Description	Fichier	Gravité
R-01	`MfaRateLimitGuard` appliqué sur `POST /auth/reauth` (hors périmètre MFA dans la spec). Risque de non‑conformité si la spec ne prévoit pas ce rate limit.	mfa-management.controller.ts / reauth.controller.ts	MAJEUR
R-02	Absence explicite d’un check `userId` ↔ `keycloakUserId` dans le service : la contrainte INV‑238‑02 repose sur un mapping implicite.	mfa-management.service.ts	MAJEUR
R-03	Gestion d’erreur non visible dans la couche service (ex. `verifyTotp` sans handling explicite pour sessionId manquant). Risque d’erreurs non alignées ERR‑238‑*.	mfa-management.service.ts	MINEUR
R-04	`method` est implicitement nullable côté DTO/service, alors que la spec fixe `TOTP` comme valeur unique supportée.	mfa-management.service.ts / mfa-status.dto.ts	MINEUR

✅ Guards alignés avec les invariants (JWT, reauth, rate limit) côté /user/mfa/*.
⚠️ Pas d’indication sur la validation de TotpVerifyRequestDto (assumée par ValidationPipe global).

✅ Flux logique conforme (init → verify → recovery codes, disable/regenerate via credentialId).
⚠️ Dépendances implicites : stockage sessionId en Redis non contractuel dans la spec (à aligner).
⚠️ sessionId non trouvé : comportement non défini dans le plan/spec.

⚠️ Le rate limit MFA est appliqué sur /auth/reauth (non explicitement dans la spec).