Système de droits

**Sebsheep** · 24/08/2014, 23h28

Bonjour,

Je souhaite réaliser un système permettant de créer des "projets", et je souhaiterais implémenter une gestion des droits relativement fine sur ces projets.

Pour parler concrètement, voici l'organisation des données :
- un membre (que j'appellerai le créateur) crée un projet. Il peut désigner un ou plusieurs "directeurs" sur le projet. Le créateur a bien sur tous les droits sur ledit projet.
- les directeurs peuvent recruter d'autres membres (que j'appellerai des "ouvriers") sur le projet dont ils ont la direction et ont quelques droits de plus que les ouvriers.
- les ouvriers peuvent seulement se connecter au projet, consulter les informations en lecture et poster des messages dans un forum dédié.

Je distingue donc 3 roles hiérarchisés comme suit : propriétaire > directeur > ouvrier. La situation serait donc simple s'il n'y avait qu'un seul projet, j'utiliserai 3 rôles statiques définis dans le security.yml. Mais ici, on peut créer autant de projets qu'on souhaite.

Je n'ai pas réussi à trouver quelque chose qui permet d'implémenter directement cette hiérarchie de rôles dynamiques, alors que cela me semble relativement classique comme organisation.

Ce que j'ai pensé à faire :

pour chaque projet créer deux groupes : PROJECT_A_DIRECTOR, PROJECT_A_WORKER
créer un voter qui détermine le bon niveau d'accès suivant si l'utilisateur est le créateur ou s'il appartient à l'un des groupes sus-cités

Cette solution est-elle "conforme à l'esprit SF2" ? Cela ne me semble pas très bien car l'héritage des rôles serait encodé dans le voter avec "if". J'aimerais bien pouvoir dire explicitement "pour cette entité projet, il y a tels rôles, qui se hiérarchisent ainsi", comme on le ferait avec des rôles statiques ; et cerise sur le gâteau, pouvoir gérer ces droits directement grâce au firewall. Encore une fois, je suis étonné que rien n'existe pour gérer ce genre d'architecture ; n'y a-t-il pas une solution plus élégante ?

**Nico_F** · 25/08/2014, 09h53

Hello,

Je pense que ces trois rôles suffisent.

S'il s'agit d'une relation OneToMany, la sécurité se gère simplement : "Si tu ne fais pas partie du projet, tu n'as aucun droit, tu dégages. Si tu fais partie du projet, voyons voir ton rôle pour savoir ce que tu as le droit de faire". Tu peux garder tes rôles dans le security.yml comme tu le fais actuellement.

Par contre, s'il s'agit d'une relation ManyToMany : admettons que tu es créateur du projet A, tu es aussi ouvrier du projet B et que tu ne fais pas du tout partie du projet C.
Là je pense du coup que les rôles ne sont plus uniquement des rôles au sens strict du terme, mais font partie intégrante de tes problématiques métier : ça va donc se jouer dans ton modèle (et donc dans ta BDD aussi). Tu as alors plusieurs possibilités :

- La première qui est la plus évidente mais la plus pénible consiste à rajouter le rôle dans la table intermédiaire entre Projet et Membre. Je trouve que c'est la plus pénible car elle t'oblige à faire une entité pour la table intermédiaire et donc traiter deux relation ManyToOne au lieu d'une ManyToMany. Je déconseille fortement ce genre de pratique, mais parfois on peut ne pas avoir le choix.
- La deuxième serait de définir des groupes pour chaque projet : il y a le projet A qui a un groupe de créateurs (même s'il n'y en a qu'un), un groupe de directeurs, et un groupe d'ouvriers. Le projet B a aussi ces trois groupes etc. Tu auras autant de groupe que de 'projets x 3'. Un membre fait alors partie d'un ou plusieurs groupes (et le groupe appartient au projet).

C'est directement l'appartenances à ces groupes qui déterminent tes droits sur chaque projet. Tu n'es alors plus obligé d'utiliser ton security.yml.

++

**Sebsheep** · 25/08/2014, 11h21

Merci pour ta réponse. Il s'agit effectivement d'une relation ManyToMany : on peut être créateur d'un projet et directeur sur un autre, et rien du tout sur un troisième.

Donc si je comprends bien, tu me recommandes en gros de réaliser ce que j'avais proposé avec les différents groupes. Mais je ne vois pas bien l'intérêt du groupe "créateur du projet A", à part surcharger la base avec un groupe supplémentaire.

Tu n'es alors plus obligé d'utiliser ton security.yml.

Justement, j'avais plutôt envie d'utiliser ce fichier, pour bien séparer les autorisations du reste.

**Nico_F** · 25/08/2014, 13h52

Oui, si le groupe créateur te dérange tu peux le dégager, mais c'est plus pour une question d'homogénéité quand tu feras tes requêtes par la suite que je l'ai proposé.

Dis moi ce que tu préfères :

"Retourne moi les users de tous les groupes du projet A" (Relation 'Projet-Groupe' et 'Groupe-User')

ou bien

"Retourne moi les users de tous les groupes du projet A et retourne moi aussi le créateur du projet A" (Relation 'Projet-Groupe', 'Groupe-User', et 'Projet-User')

Pour ce qui est de la gestion des droits et des groupes, je ne pense pas que tu puisses utiliser le fonctionnement "standard" du composant security car ton utilisation n'est pas "standard".
Le composant est prévu pour fonctionner avec un système de rôles et de groupes plus ou moins statiques. Si une action de ton site (typiquement créer un projet) engendre de nouveaux rôles et de nouveaux groupes, j'ai du mal à voir comment tu pourrais intégrer ça dans ton security.yml.

Dans ton cas, les rôles ne sont pas uniquement des histoires d'accès, ils font partie de ton modèle métier, et c'est pour cette raison que je te suggère de gérer ça toi même.

Il est possible qu'une meilleure solution existe, mais je ne la connais pas pour le moment.