Matrice d'autorisation

Quand et comment modifier la matrice d'autorisation (authorization-matrix.ts) pour ajouter une nouvelle entite.

Matrice d'autorisation

La matrice d'autorisation (authorization-matrix.ts) definit quels endpoints sont accessibles pour chaque entite de token API.

Quand modifier la matrice ?

Situation Action requise
Site consommant blog, portfolio ou docs Rien a faire — deja configure
Nouveau module avec endpoints publics Ajouter l'entite dans la matrice
Nouvel endpoint sur un module existant Ajouter le path dans l'entite existante

Structure de la matrice

Fichier : backend/src/auth/config/authorization-matrix.ts

export const AUTHORIZATION_MATRIX = {
  [ENTITIES.BLOG]: {
    endpoints: [
      {
        path: '/public/posts',
        methods: { GET: PERMISSIONS.READ },
      },
      {
        path: '/public/posts/:slug',
        methods: { GET: PERMISSIONS.READ },
      },
      // ... autres endpoints
    ],
  },
  // ... autres entites
};

Chaque entree associe :

  • Une entite (blog, portfolio, documentation, etc.)
  • Des endpoints avec leur path relatif
  • Les methodes HTTP autorisees et la permission requise

Ajouter une nouvelle entite

Exemple : ajouter un module course avec des endpoints publics.

Etape 1 : Declarer l'entite

Dans authorization-matrix.ts, ajoutez la constante si elle n'existe pas :

// Dans ENTITIES (si pas deja present)
COURSE: 'course',

Etape 2 : Ajouter les endpoints

[ENTITIES.COURSE]: {
  endpoints: [
    {
      path: '/public/courses',
      methods: { GET: PERMISSIONS.READ },
    },
    {
      path: '/public/courses/:slug',
      methods: { GET: PERMISSIONS.READ },
    },
  ],
},

Etape 3 : Rebuild le backend

docker-compose up -d --build backend

Etape 4 : Creer un token avec la nouvelle entite

Dans le dashboard, creez un token avec l'entite course et la permission read.

Comment fonctionne la validation

Requete entrante
  -> ApiTokenGuard extrait le token
  -> Hash SHA256 -> lookup DB
  -> Recupere les entites et permissions du token
  -> RouteResolver normalise le path de la requete
  -> Match dans AUTHORIZATION_MATRIX : entite + path + methode
  -> Si match et permission suffisante -> autorise
  -> Sinon -> 403 Forbidden

Points importants

  • Les paths dans la matrice sont relatifs (sans le prefix /api/blog/v1)
  • Le RouteResolver normalise automatiquement les paths entrants
  • Les parametres dynamiques utilisent la notation :param (ex: :slug, :id)
  • Apres toute modification, il faut rebuild et redemarrer le backend