Le sceau de la guilde

Exercice 4 sur 6 du chapitre 5 · 250 XP · 5 objectifs vérifiés par des tests

Notions abordées : access_tokenPare-feu sans étatAccessTokenHandlerInterface401

Catastrophe : un petit malin a réservé toutes les tables du Dragon Ivre pour les dix prochaines années, sous le nom de « Sauron ». N'importe qui peut envoyer un pigeon, c'est bien le problème.

Gorm a donc passé un accord avec les guildes. Chacune reçoit un sceau, un jeton secret, à présenter à chaque réservation :

Authorization: Bearer lames-d-argent-7f3a9c

Les sceaux de démonstration sont affichés par app:fonder-guildes, dans la console.

Votre mission

  1. Dans security.yaml, ajoutez un pare-feu api pour les chemins ^/api :
    • sans état (stateless: true) : pas de session ni de cookie, le sceau accompagne chaque requête ;
    • authentifié par jeton d'accès (access_token), avec votre SceauHandler.
  2. Complétez SceauHandler : retrouvez la guilde qui porte ce sceau. Si aucune ne le porte, le sceau est refusé.
  3. Réservez POST /api/reservations aux guildes (ROLE_GUILDE). La carte, elle, reste ouverte à tous.
  4. Rattachez chaque réservation à la guilde qui l'a faite.

Le piège de l'ordre

Symfony choisit un seul pare-feu par requête : le premier dont le motif (pattern) correspond. main n'a pas de motif, il prend donc toutes les requêtes. Le pare-feu api doit être déclaré avant lui.

Pourquoi « sans état » ?

Un parchemin n'est pas un navigateur : il ne garde pas de cookie de session. Avec stateless: true, Symfony vérifie le sceau à chaque requête et n'ouvre jamais de session. Autre avantage : une session du site, celle de Bruna par exemple, ne donne aucun droit sur l'API.