Voter Symfony : contrôler l'accès à un objet

Un voter Symfony décide d'un droit qui dépend de l'objet visé, ce plat ou cette commande, et de qui le demande : là où un rôle ne suffit plus.

final class PlatVoter extends Voter
{
    protected function supports(string $attribute, mixed $subject): bool
    {
        return 'PLAT_MODIFIER' === $attribute && $subject instanceof Plat;
    }

    protected function voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token, ?Vote $vote = null): bool
    {
        // Le patron, ou le créateur du plat ; sinon, refusé.
    }
}
// Dans le contrôleur : #[IsGranted('PLAT_MODIFIER', 'plat')]

Un rôle dit ce qu'est un utilisateur, pas s'il peut modifier telle ressource. Le voter répond à deux questions : supports(), est-ce que je m'occupe de cet attribut et de ce sujet ; puis voteOnAttribute(), est-ce autorisé. Symfony interroge tous les voters, et ceux qui ne sont pas concernés s'abstiennent. On le sollicite avec #[IsGranted] et un sujet, isGranted() dans le contrôleur ou is_granted() dans Twig. Le piège : un supports() qui ne reconnaît jamais son sujet, par exemple un instanceof sur une classe mal importée. Le voter s'abstient sans bruit, et l'accès est refusé à tout le monde.

Les exercices font écrire le voter qui réserve à chaque cuisinier de la taverne la modification de ses propres plats, le patron gardant tous les droits, puis chercher, dans une configuration de sécurité sabotée, le voter qui ne se prononce plus.