access_control dans Symfony : protéger des URL par rôle
La clé access_control de la sécurité Symfony associe des motifs d'URL aux rôles exigés : la première règle qui correspond au chemin décide de l'accès.
security: # Le patron a aussi tous les droits d'un cuisinier. role_hierarchy: ROLE_PATRON: [ROLE_CUISINIER] # Seule la première règle qui correspond s'applique. access_control: - { path: ^/cuisine, roles: ROLE_CUISINIER } # Une règle « ^/ » en PUBLIC_ACCESS placée au-dessus ouvrirait aussi la cuisine.
Chaque règle combine un path, une expression régulière, avec au besoin methods, host ou ip, et les roles exigés. Symfony les lit dans l'ordre et s'arrête à la première qui correspond : un visiteur anonyme est envoyé vers la page de connexion, un utilisateur connecté sans le rôle reçoit un 403. role_hierarchy évite de répéter les rôles d'un compte qui en englobe d'autres. Le piège : l'ordre des règles. Une règle ^/ en PUBLIC_ACCESS écrite en tête correspond à toutes les URL et rend muettes celles qui suivent. De même, un rôle mal orthographié n'est jamais une erreur de configuration : c'est un rôle que personne n'a.
Les exercices font fermer la cuisine de la taverne au public, avec un utilisateur en mémoire au mot de passe haché, la connexion par formulaire et une règle sur /cuisine, puis enquêter sur une configuration de sécurité « renforcée » par Pipin, où des clients entrent en cuisine et où le patron ne voit plus le lien qui y mène.
2 exercices font travailler cette notion, en écrivant du code dans le navigateur.
Dans les parcours
- Qui va là ? Symfony pour les devs PHP · chapitre 4 : Les clés de la taverne
- 🐉 Boss : les clés volées Symfony pour les devs PHP · chapitre 4 : Les clés de la taverne