Récupérer la hiérarchie des rôles

Bonjour !

Aujourd'hui, en travaillant sur une application Symfony, je me rends compte quelque chose qui ne fait pas vraiment mon beurre.

L'application en question a plusieurs rôles, organisés avec une simple hiérarchie dans security.yml pour diverses raisons. Du fait de la hiérarchie, je pensais logiquement tester les rôles les moins élevés plutôt qu'explicitement tous les rôles qui pourraient avoir accès. Seulement, je me rends compte que la hiérarchie n'est apparemment pas gérée comme je m'y attendais, en cela qu'un utilisateur ayant le rôle ROLE_SUPER_ADMIN n'a que celui-ci, alors qu'il est bien défini dans la hiérarchie. Qu'il n'y ait eu que les rôles explicitement définis comme enfants, passe encore, mais ce n'est même pas le cas.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

security:
    role_hierarchy:
        ROLE_PETIT:
          - ROLE_USER
        ROLE_ADMIN:
          - ROLE_PETIT
          - ROLE_MOYEN
        ROLE_SUPER_ADMIN:
          - ROLE_ALLOWED_TO_SWITCH
          - ROLE_ADMIN

J'ai pu constater qu'en base de données, les rôles ne sont pas enregistrés tel quels, la méthode getRoles() retourne un tableau avec un seul rôle selon la valeur simple en BDD.

Maintenant, plusieurs questions :

• est-ce qu'il y a besoin de récupérer la hiérarchie depuis le rôle le plus élevé dans l'entité même ou normalement Symfony s'en charge ?
  D'après ce que j'ai pu voir, il y a bien des récupérations de hiérarchies dans les classes de sécurisation, mais du coup, je ne comprends pas pourquoi ça ne fonctionne pas.
• est-ce qu'il y a moyen de récupérer cette hiérarchie dans l'entité au besoin ?
  Je me vois mal redéfinir les services impliqués juste pour ça, et intercaler un quelconque wrapper n'est pas vraiment propre

Merci d'avance 

Pourquoi veux-tu récupérer la hiérarchie des rôles ? Normalement la méthode isGranted de l'AuthorizationChecker suffit.

Sinon tu peux récupérer le paramètre security.role_hierarchy.roles du conteneur, il est censé contenir ta config.

C'est aussi ce que je pensais, mais soit j'ai un autre souci du fait d'un code particulier (ce qui me surprendrait assez), soit isGranted ne passe pas par une vérification de la hiérarchie, parce que mes utilisateurs, bien qu'ayant le rôle super admin, ne sont pas considérés comme ayant le rôle admin ou n'importe quel autre.

Oui, mais le faire depuis une entité, pas terrible…
Je parle de cette option parce que pour FOSUserBundle, si je me souviens bien, ce sont tous les rôles alloués (donc celui "choisi" ainsi que les rôles hérités) qui sont persistés en base de données, par défaut. Du coup, je me demandais si vraiment Symfony regardait la hiérarchie.

isGranted tient compte de la hiérarchie ; le problème vient probablement du code.

Et oui il ne faut pas faire ça dans une entité, normalement on n'en a même pas besoin.

Bon…

Actuellement, j'ai quelque chose de ce genre dans mon entité :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php
public function getRoles()
{
    switch ($this->getRole()) {
        case 'super admin':
            $roles = array('ROLE_SUPER_ADMIN');
            break;
        case 'admin':
            $roles = array('ROLE_ADMIN');
            break;
        case 'moyen':
            $roles = array('ROLE_MOYEN');
            break;
        case 'petit':
            $roles = array('ROLE_PETIT');
            break;
        case 'user':
        default:
            $roles = array('ROLE_USER');
            break;
    }
    return $roles;
}

Est-ce parce qu'il n'y a qu'un élément dans ce tableau que Symfony ne va pas chercher plus loin ?

Ça ne devrait pas poser problème.

Si j'ai bien compris isGranted('ROLE_ADMIN') sur un super admin renvoie false ?

Vérifie la valeur du paramètre que j'ai mentionné plus haut.

J'ai bien la hiérarchie complète et correcte qui s'affiche, justement, c'est une des premières choses que j'ai vérifié, et par acquit de conscience, je viens de le refaire. C'est toujours OK.

Exactement. Et c'est un comportement similaire pour tous les rôles quand on vérifie un "sous-rôle".

Je pense avoir compris. Après avoir vu le même problème sur StackOverflow je pense que c'est simplement le fait de référencer des rôles personnalisés absents de la racine dans l'héritage qui fait foirer le bordel.

Si tu testes avec

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

security:
    role_hierarchy:
        ROLE_PETIT:
          - ROLE_USER
        ROLE_MOYEN:
          - ROLE_PETIT
        ROLE_ADMIN:
          - ROLE_MOYEN
        ROLE_SUPER_ADMIN:
          - ROLE_ALLOWED_TO_SWITCH
          - ROLE_ADMIN

Est-ce que ça fait le job ?

OK, je suis désolé, il y avait des contraintes d'affichage sur les rôles qui n'étaient pas correctes en fonction de la hiérarchie, donc ça a faussé mon jugement.  Pas besoin pour moi de spécifier les "plus petits rôles" dans la configuration, ça fonctionne pour is_granted() dans mes vues et pour isGranted() dans mon contrôleur (logique, c'est la même méthode au final).