Discussion :

[Droide63000]

Bonjour à tous,
Depuis quelques semaines, je me suis mis sur le framework symfony2 et il y a une chose que j'aimerai faire mais sur laquelle je bloque.
Pour la gestion des mes utilisateurs, j'utilise le FOSUserBundle. La, il n'y a pas trop de souci, je lu la documentation et j'ai réussi à le mettre en place

Par contre, j'aimerai maintenant créer des groupes utilisateurs pouvant avoir des permissions comme par exemple (ARTICLE_CREATE, ARTICLE_READ, ARTICLE_UPDATE, COMMENTAIRE_READ, COMMENTAIRE_CREATE,etc...). Et la problème, je ne vois pas comment faire cela (surtout au niveau de isGranted).

J'ai créé mon entité groupe qui extends de BaseGroup mais lui contient des rôles définit dans la config YML(ROLE_ADMIN, ROLE_USER,...)..

Je ne sais pas si je suis très claire mais merci d'avance pour l'aide que vous allez pouvoir m'apporter

[Nico_F]

Salut.

Il ne faut pas chercher à faire des groupes correspondant à chacune de tes actions, mais plutôt définir quel groupe est autorisé à y accéder.
Avoir un User qui possède 50 rôles est moins intéressant que d'avoir une route qui autorise un ou deux groupes de sécurité maximum.
De manière générale, tu ne devrais pas avoir besoin d'avoir beaucoup de groupes de sécurité : un groupe "User", "Admin", "Super admin" potentiellement deux ou trois autres groupes propres à tes problématiques métier mais rarement plus.

Pour chaque route/action, tu auras la possibilité de gérer l'accès à un ou plusieurs groupes.
Typiquement, une action read() sera accessible à tout le monde ou presque tandis qu'une action de modification ou de suppression ne sera accessible qu'à un rôle admin ou superadmin. (par exemple)

Je ne sais pas comment fonctionne le FosUserBundle, ni ce qu'il offre comme fonctionnalité supplémentaire, mais dans ton cas précis, rien que Symfony ne soit capable de faire seul.
La documentation de Symfony est très claire concernant la sécurité et la gestion des accès et des rôles : http://symfony.com/fr/doc/current/book/security.html

Bonne lecture.

[Droide63000]

Ok mais j'aimerais bien ne pas faire l'autorisation suivant les groupes mais suivant des credentials que contiendrais ces groupes (ENTITEA_CREATE, ENTITEA_UPDATE,etc,etcetc)..
Il me semble que c'est ce que faisais symfony1.4 avec sfGuardUser, sfGuardGroup et sfGuardPermissions non?

[gototog]

Quel est ton scenario métier qu'on puisse te répondre d'une manière plus concrète?

[Droide63000]

J'ai des utilisateurs qui doivent se connecter à une application (username et password) afin de pouvoir l'utiliser.

Dans cette application, j'ai par exemple une entité "Banque" qui va contenir une pk, un libelle, un code banque etc etc...
J'ai aussi un controller BanqueController qui va avoir différentes opération comme indexAction (permettant de lister les banques), addAction (permettant d'ajouter une banque), removeAction (permettant de supprimer une banque)...

Maintenant, tout les utilisateurs n'ont pas le droit de modifier, ajouter, créer ou supprimer une banque.
Du coup oui, je pourrai travailler avec les rôles mais pour ma part, je trouve que la gestion des rôles n'est pas assez poussée.

Ainsi, j'aimerai que l'utilisateur A qui se connecte et qui a la permission BANQUE_CREATE puisse ajouter une banque mais que l'utilisateur B a qui on a enlevé cette permissions ne le puisse pas. Mais rien ne lui empêche de modifier, supprimer une banque si il a les bonne permissions (BANQUE_EDIT et BANQUE_DELETE)
Et donc en clair, on aurait autant de permission que d'action..

Maintenant on mets les permissions au niveau des groupes comme par exemple groupe1, groupe2 et chaque utilisateur possede un ou plusieurs groupes et donc imaginons l'edition d'un groupe :


GROUP1 : Groupe utilisateur A

Entité	Create	Read	Update	Delete
Banque	Oui	Oui	Oui	Oui

GROUP2 : Groupe utilisateur B

Entité	Create	Read	Update	Delete
Banque	Non	Oui	Oui	Oui

Je suis peut-être pas assez clair.. et je m'en excuse

[damiensan]

Bonjour,

Si tu utilises FOSUserBundle, les groupes peuvent avoir des permissions de la même manière qu'un utilisateur peut avoir une ou des permissions.
Ces permissions sont configurables dans le fichier de sécurité.

Je suis d'accord avec toi le système de sécurité et de rôles me paraît affreux. C'est pourquoi j'ai créé une surcouche pour adapter le composant de sécurité à mes besoins.

Je voulais faire comme toi. Des utilisateurs liés à des groupes et ces groupes ayant des permissions liées à des routes.

Contrairement à ce que dit Nico_F :

De manière générale, tu ne devrais pas avoir besoin d'avoir beaucoup de groupes de sécurité : un groupe "User", "Admin", "Super admin" potentiellement deux ou trois autres groupes propres à tes problématiques métier mais rarement plus.

J'ai besoin de très nombreux groupes, car mon site ne se résume pas à un blog ou un petit site entre amis, mais à une application professionnelle. Du coup les utilisateurs sont très nombreux, les groupes également, ainsi que les permissions.

Pour résoudre mon problème. Cela a été relativement simple.

1 / J'ai créé une tâche qui liste l'ensemble des routes de mon appli back office (elles sont toutes préfixées par admin_) et qui les stocke en base dans une table permission. Par défaut je considère que toutes mes routes sont sécurisées (flag en base) mais ceci est configurable

2 / J'ai créé trois modules BO pour gérer les utilisateurs, les groupes et les permissions avec sonata. Relation n-n entre user et groupes et relation n-n entra groupe et permission.

3 / J'ai créé un controlerListener qui écoute l'évent onKernelRequest. Dans ce controller je vérifie que ma route est back ou front, si back je vérifie en base si elle est sécurisée, si elle est sécurisée je vérifie dans les groupes de mon utilisateurs si la permission est présente, sinon je lance une exception AccesDenied. J'ai modifié le template de l'erreur 403 en spécifiant que "les droits sont insuffisant, contactez le service IT blablabla…"

Et voila. Je t'omets les différents détails d'implémentation. Mais voici les grandes lignes.

De cette façon je contrôle tous mes utilisateurs, mes groupes et mes permissions dans mon interface BO et je n'ai pas besoin de mettre à jour le fichier security.yml avec 450 000 lignes de rôles