mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-27 23:08:16 +02:00
7767f1f947
28 nouvelles sections intégrées dans 12 fichiers knowledge (backend risques/patterns, frontend risques/patterns, workflow risques). Couvre rate limiting, RGPD, CSP Next.js, refresh token TOCTOU, catch-all Prisma, distinction 401/403, tests E2E Playwright, etc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
---
|
|
title: Backend — Patterns : Général
|
|
domain: backend
|
|
bucket: patterns
|
|
tags: [auth, helpers, architecture, rbac]
|
|
applies_to: [implementation, review, architecture]
|
|
severity: medium
|
|
validated_on: 2026-04-07
|
|
source_projects: [RL799_V2]
|
|
---
|
|
|
|
# Backend — Patterns : Général
|
|
|
|
> Extrait de la base de connaissance Lead_tech. Voir `knowledge/backend/patterns/README.md` pour l'index complet.
|
|
|
|
---
|
|
|
|
<a id="pattern-helper-auth-centralise-enrichissable"></a>
|
|
## Pattern : Helper d'authentification centralisé enrichissable
|
|
|
|
- Objectif : éviter la duplication de logique RBAC dans chaque service en centralisant un seul `requireRoleAccess` dans `lib/authHelpers.ts`.
|
|
- Contexte : chaque nouveau service réimplémentait `requireRoleAccess` localement avec des variations subtiles (certains retournaient `{ email }`, d'autres `{ email, role }`).
|
|
- Quand l'utiliser : dès qu'un endpoint nécessite une vérification de rôle ou d'authentification.
|
|
- Validé le : 07-04-2026
|
|
- Contexte technique : backend / RBAC — RL799_V2 epics 7-8-9
|
|
|
|
### Règle
|
|
|
|
- Un seul `requireRoleAccess` dans `lib/authHelpers.ts`, retournant toutes les infos du token utiles (email, role, sub).
|
|
- Quand un service a besoin d'une info supplémentaire : enrichir le helper centralisé, pas le copier.
|
|
- Le retour riche est rétrocompatible : les consommateurs existants utilisent ce dont ils ont besoin via destructuring.
|
|
|
|
### Signal review
|
|
|
|
- Tout service qui importe `verifyToken` directement ET fait son propre check RBAC est suspect de duplication.
|
|
|
|
---
|
|
|
|
<a id="pattern-extension-service-par-type-rbac"></a>
|
|
## Pattern : Extension d'un service existant par type avec RBAC granulaire
|
|
|
|
- Objectif : éviter la duplication de service quand un nouveau besoin est fonctionnellement identique à un service existant mais avec des restrictions d'accès différentes.
|
|
- Contexte : ajout d'un nouveau type de communication (ex: `vm`) avec restrictions RBAC spécifiques dans un service communications existant.
|
|
- Quand l'utiliser : quand le nouveau besoin utilise le même modèle de données et le même CRUD que le service existant, seules les restrictions d'accès changent.
|
|
- Quand l'éviter : quand le modèle de données diverge (champs spécifiques au nouveau type) — dans ce cas, un service dédié est préférable.
|
|
- Validé le : 08-04-2026
|
|
- Contexte technique : backend / architecture — RL799_V2 story 18-7
|
|
|
|
### Règle
|
|
|
|
Préférer étendre le service avec un nouveau type (enum/Set) et ajuster les restrictions RBAC par type, plutôt que dupliquer le service.
|
|
|
|
### Avantages
|
|
|
|
- Un seul repository, un seul endpoint, même format de réponse
|
|
- Tests existants couvrent la non-régression
|
|
- Moins de code à maintenir
|
|
|
|
### Signal review
|
|
|
|
- Nouveau service qui réplique le CRUD d'un service existant avec un filtre additionnel → candidat à la fusion par type
|