Symfony 8.2 : des jokers dans la hiérarchie des rôles

Ce qui se passe

Symfony 8.2 retouche role_hierarchy, le bloc qui déclare quels rôles en incluent d'autres. Dans une application qui multiplie les rôles, il s'allonge vite, et savoir ce qu'un utilisateur possède réellement devient difficile. Deux réponses : des jokers pour écrire moins, des outils pour voir le résultat.

Les jokers

Une clé de la hiérarchie peut désormais contenir * et viser une famille entière. Exemple écrit pour cette fiche :

security:
    role_hierarchy:
        'ROLE_BLOG_*': [ROLE_BLOG_READER, ROLE_USER]

Tout rôle en ROLE_BLOG_ reçoit alors ROLE_BLOG_READER et ROLE_USER, même s'il n'est déclaré nulle part : un utilisateur doté de ROLE_BLOG_COMMENTER en hérite sans ligne supplémentaire.

Deux règles :

• * n'est un joker qu'entre deux tirets bas (ROLE_*_FOO) ou après un tiret bas en fin de nom (ROLE_BAR_*). ROLE_BLOG* et ROLE_*BLOG restent des noms ordinaires.
• Un joker est un motif, jamais un rôle, et ne s'écrit qu'en clé. is_granted('ROLE_BLOG_*') cherche un rôle portant exactement ce nom ; getReachableRoleNames() et getParentRoleNames() ne renvoient jamais de motif.

Voir ce qui est vraiment accordé

• debug:roles affiche les rôles effectivement attribués ; --tree montre pourquoi chacun l'est, jokers compris.
• Le graphe Mermaid que produisait debug:security:role-hierarchy depuis Symfony 7.4 apparaît maintenant dans le panneau Security du profileur.

Ce que ça change

Le joker supprime des lignes mais déplace une décision. Sans lui, un nouveau rôle n'a que ce qu'on lui donne. Avec ROLE_BLOG_*, il hérite dès sa création de ce que reçoit la famille — y compris un rôle qu'on voudrait restrictif, un ROLE_BLOG_BANNED par exemple. La sortie de debug:roles --tree a donc sa place dans toute revue de code qui touche à la sécurité.

Jokers et debug:roles par Nicolas Rigaud, graphe dans le profileur par Damien Fernandes.

Source : New in Symfony 8.2: Role Hierarchy Wildcards and Debugging, blog Symfony, 22 septembre 2026.