L’autorisation toute seule : décider si un demandeur a le droit d’effectuer une action sur un sujet. Ni utilisateur, ni jeton, ni pare-feu dans le vocabulaire, et aucune pile d’authentification nécessaire pour que tout cela fonctionne.
Ce que ça couvre
- Des votants qui répondent à une question par une autorisation, un refus, ou rien du tout, l’abstention étant un résultat à part entière.
- Des algorithmes de combinaison qui transforment plusieurs réponses en une seule, sous leurs noms XACML, avec une correspondance exacte avec ceux de Symfony Security.
- Des politiques d’accès déclarées là où elles s’appliquent, en attributs, et composées avec
All,AtLeastOneOfetWhen. - Des décisions qui disent pourquoi : un verdict, une raison, et qui a voté dans quel sens, ce qui rend un refus diagnosticable six mois plus tard.
- Des points d’entrée sur la même mécanique : contrôleurs, règles d’URL, Twig, commandes de console, gardes de workflow, et un panneau de profileur qui montre chaque question posée par une requête.
Deux paquets
spomky-labs/access-control-lib est la bibliothèque, utilisable dans n’importe quelle application PHP : elle demande PHP et un contrat de répartiteur d’événements, et ne connaît rien à HTTP. spomky-labs/access-control-bundle l’intègre au framework Symfony complet. Les deux sont des extractions de sous-arbre en lecture seule d’access-control-framework, où se posent les tickets et les pull requests.
Pour démarrer
composer require spomky-labs/access-control-bundle// config/bundles.php
return [
// ...
AccessControl\Bundle\AccessControlBundle::class => ['all' => true],
];Il n’y a pas de drapeau enabled : enregistrer le bundle vaut activation. Dans une application qui a Symfony Security, rien de visible ne change. Vos votants continuent d’être consultés, #[IsGranted] est lu, is_granted() répond dans vos gabarits, et votre security.yaml reste octet pour octet ce qu’il était. Ce qui a changé, c’est qui décide.
Hors de Symfony, la bibliothèque tient en un objet et n’a besoin d’aucun conteneur :
$accessControlManager = new AccessControlManager(
strategies: [new PermitOverridesStrategy()],
voters: [new PostVoter()],
);
$decision = $accessControlManager->decide(new AccessRequest($requester, 'EDIT', $post));Une chose à savoir : il y a deux migrations
La première est gratuite et se fait le premier jour : installez le bundle, ne changez rien d’autre, et le composant décide. La seconde est le passage à son vocabulaire propre, fichier par fichier, à votre rythme, ou jamais. Une base de code à mi-chemin fonctionne, parce que les deux vocabulaires atteignent les mêmes votants.
Les confondre coûterait l’adoption, alors elles sont documentées à part. Et ce que la passerelle ne sait pas transporter est refusé à voix haute plutôt que répondu en silence : l’ACL au niveau du champ lève au lieu de renvoyer false, et le même réglage déclaré à la fois sur security.* et sur access_control.* arrête la compilation au lieu d’en choisir un. Une garde qui laisse passer quelqu’un est la seule panne inacceptable, et elle est silencieuse.
Où regarder ensuite
La documentation est organisée par la question que vous posez, du vocabulaire à la migration. Une application de démonstration met chaque idée derrière une vraie page, avec une suite de tests qui s’appuie sur les décisions plutôt que sur les codes de statut. Le code source est sur GitHub, sous licence MIT.
Une série d’articles en prend une pièce à la fois : le vocabulaire, les votants, les algorithmes de combinaison, les points d’entrée, les tests et la migration.