PD-28 — Rétrospective¶
1. Contexte¶
| Champ | Valeur |
|---|---|
| Story ID | PD-28 |
| Titre | Validation et révocation sessions |
| Domaine | auth-identity |
| Projet | backend |
| Date complétion | 2026-01-28 |
| Verdict | En attente de revue formelle |
2. Métriques¶
| Métrique | Valeur |
|---|---|
| Tests unitaires + intégration | 48 |
| Composants | 7 |
| Catégories TC | TC-INV(4), TC-NOM(5), TC-ERR(4), TC-NEG(4), TC-NR(2) |
3. Learnings clés¶
-
Guards composites difficiles à tester : L'instanciation d'un guard dans un autre (
new OidcJwtAuthGuard()dans constructeur) crée une dépendance forte qui complique le mocking. -
Taxonomie normative = enums TypeScript : Les
JustificationCodeetPd27EventRefdéfinis dans la spec se traduisent directement en code. -
Store de révocation critique : La disponibilité et cohérence du store sont essentielles. Un store en mémoire suffit pour les tests mais pas pour la production distribuée.
-
Conversion vitest → jest : Les fichiers initiaux utilisaient
vi.fn()mais le projet utilise Jest. Toujours vérifier le runner de tests du projet.
4. Patterns applicables¶
Nouveau pattern : Interface store de révocation¶
Pour faciliter le swap mémoire ↔ Redis :
interface SessionRevocationStore {
isRevoked(sessionId: string): Promise<boolean>;
revoke(sessionId: string, scope: RevocationScope): Promise<void>;
getRevocationEntry(sessionId: string): Promise<RevocationEntry | null>;
}
Nouveau pattern : Mapping événement → portée¶
const EVENT_SCOPE_MAP: Record<Pd27EventRef, RevocationScope> = {
LOGOUT_GLOBAL: 'global',
DEVICE_REVOKE: 'device',
PASSWORD_CHANGE: 'global',
// ...
};
5. Signal CLAUDE.md¶
Priorité moyenne : Documenter le pattern de guard composite NestJS.
### Guards composites NestJS — Injection vs instanciation (2026-02-XX)
**ÉVITER** :
```typescript
constructor() {
this.oidcJwtAuthGuard = new OidcJwtAuthGuard(); // Difficile à mocker
}
PRÉFÉRER :
constructor(private readonly oidcJwtAuthGuard: OidcJwtAuthGuard) {}
// Ou déléguer la logique à un service injectable
6. Conclusion¶
PD-28 a implémenté la validation et révocation des sessions avec intégration aux événements PD-27. Les principaux défis concernaient la testabilité des guards composites et la gestion du store de révocation. Le store in-memory est une dette technique acceptée pour le MVP, à remplacer par Redis pour la production.
Rétrospective générée 2026-02-19 (Étape 10 batch auth-identity)