mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-27 14:58:16 +02:00
72758c1adc
Backend: 21 entrées (general, prisma, contracts, auth, patterns) Frontend: 9 entrées (navigation, tests, general, performance, patterns) Workflow: 5 entrées (story-tracking) Nouveau fichier: backend/patterns/general.md 95_a_capitaliser.md purgé. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.5 KiB
1.5 KiB
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.mdpour l'index complet.
Pattern : Helper d'authentification centralisé enrichissable
- Objectif : éviter la duplication de logique RBAC dans chaque service en centralisant un seul
requireRoleAccessdanslib/authHelpers.ts. - Contexte : chaque nouveau service réimplémentait
requireRoleAccesslocalement 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
requireRoleAccessdanslib/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
verifyTokendirectement ET fait son propre check RBAC est suspect de duplication.