Backend + sfGuardDoctrine + droits

Version imprimable

13/08/2010, 16h31
nawbacan

Backend + sfGuardDoctrine + droits

hello,
j'ai un projet (application frontend + backend )sur lequel j'ai une gestion de droits gérée avec le SfGuardDoctrine plugin.
Cette gestion fonctionne très bien.
Elle est gérée en backend.
Mon problème est le suivant :
J'ai remarqué que les user existant dans le système ont tous accès aux backend et au frontend. et je peut ensuite spécifier des droits selon les permissions attribuées au groupe dont fait partie l'utilisateur.
Est-il possible d'interdire l'accès à l'un des applications (dans mon cas le backend) à un/des groupes d'utilisateurs. ?

je précise que je ne veut pas utiliser le role de super admin, bkp trop dangereux.
merci
13/08/2010, 16h57
Michel Rotta

Si je comprends bien, tu as des utilisateurs qui ont accès au frontend (et besoin de s'y logguer) et d'autre qui ont accès au frontend et au backend.

Et tu voudrais que les utilisateurs qui n'ont accès qu'au frontend, ne puissent aller plus loin qu'une tentative avorté de loggin sur le backend (on ne pourra empécher, au moins, l'affichage du formulaire de loggin).
16/08/2010, 09h43
nawbacan

Citation:

Envoyé par mimi68

Si je comprends bien, tu as des utilisateurs qui ont accès au frontend (et besoin de s'y logguer) et d'autre qui ont accès au frontend et au backend.

Et tu voudrais que les utilisateurs qui n'ont accès qu'au frontend, ne puissent aller plus loin qu'une tentative avorté de loggin sur le backend (on ne pourra empécher, au moins, l'affichage du formulaire de loggin).

hello,

exactement ! j'ai pas trop pus m'y pencher depuis vendredi passé. Mais je me demande si je dois pas surcharger la méthode d'autentification du plugin sfDoctrineGuard.
16/08/2010, 13h08
Michel Rotta

Je ne pense pas que surcharger la méthode soit une bonne solution.

Perso, j'ai un menu qui n'affiche que les options pour lesquel une personne à des droits. Donc, un quidam qui déboule en admin à droit, dans le menu à l'option "logout", un point c'est tout ! :lol:

Si non, tu peux spécifier le module et l'acion à exécuter juste après le login.

Dans le executeApresLogin() tu tests l'utilisateur, si non, logout... Cela devrait marcher, proprement.
16/08/2010, 14h09
nawbacan

Citation:

Envoyé par mimi68

Je ne pense pas que surcharger la méthode soit une bonne solution.

Perso, j'ai un menu qui n'affiche que les options pour lesquel une personne à des droits. Donc, un quidam qui déboule en admin à droit, dans le menu à l'option "logout", un point c'est tout ! :lol:

Si non, tu peux spécifier le module et l'acion à exécuter juste après le login.

Dans le executeApresLogin() tu tests l'utilisateur, si non, logout... Cela devrait marcher, proprement.

J'avais pensé à cet possiblité et c'est encore la plus propre. Mais je pensais qu'on pouvait agir différement.

Par contre je me permet une autre question relativement à mon projet qui a connu un changement. Les utilisateurs et les groupes auxquels il seront associés ne sont seront pas gérés dans symfony mais dans une application externe sur le même serveur, ce qui veut dire dans une autre bd.
Les permissions seront elles gérées dans mon applic.

J'ai lu a pas mal de places que de modifier le plugin sfDoctrineGuard n'était pas une bonne idée, mais je n'aurai peut-etre pas le choix. aussi je me dit que si je veut une gestion de droits dans mon applic je suis quasi obligé de modifier ce plugin pour acceder au droits en externe.
16/08/2010, 15h06
Michel Rotta

Il faut plus d'informations sur l'application qui va gérer les utilisateurs et les groupes et comment tu vas pouvoir y accéder d'une manière sécurisée (on parle là, de vérification du mot de passe, il faut être sur qu'il ne puisse être intercepté dans une table d'attente par exemple...
16/08/2010, 15h47
nawbacan

Citation:

Envoyé par mimi68

Il faut plus d'informations sur l'application qui va gérer les utilisateurs et les groupes et comment tu vas pouvoir y accéder d'une manière sécurisée (on parle là, de vérification du mot de passe, il faut être sur qu'il ne puisse être intercepté dans une table d'attente par exemple...

je te remercie tout d'abord pour tes réponses !

le schéma est le suivant :
après le login, une identification LDAP est effectuée (login + password), ca c'est ok.
Ensuite si le user est trouvé dans ldap, une requete sql est effectuée sur la base de l'application de gestion des groupes (application php/mysql) qui demande la liste des groupes de ce user. L'idée est qu'à ce moment là, je connais le/les groupes du user et je le les transmettre à symfony qui pourra attribuer les permission correspondante.
L'application de gestion des droits est sur le meme serveur ainsi que la bd. On se trouve dans un intranet sécurisé. L'accès à l'application de gestion des droits est sécurisée par un log/password qui lui est propre.

Cette manière de procéder a deja été utilisée pour des applic similaires, mais sous Zend ou la gestion est quelques peu différente.
ps : je connaissai pas le concept de table d'attente.
16/08/2010, 16h57
nawbacan

hello,
j'ai pas mal fouillé le net aujourd'hui pour trouver une solution.
j'ai l'impression que 2 questions ressortent :
-1.peut-on gérer des permissions sans le sfDoctrineGuard plugin
-2.peut-on attribuer des droits et des groupes à un user une seul fois après le login correct. ()

Comme mon applic ne gére que les droits, tout les reste est géré par les 2 niveaux précédent d'authentifications (ldap + applic de groupes/user), je me demande si le plugin que j'ai choisi est vraiment le bon.
16/08/2010, 17h01
Michel Rotta
Pour l'authentification LDAP il existe un plugin (jamais testé par moi) qui permet de gérer les connexions bhLDAPAuthPlugin il peut servir tel quel ou d'inspiration...

Ce qui m'étonne plus est le fait de valider le login sur LDAP et les groupes par une requêtes sur une table sql autre... LDAP est capable de gérer des user et leurs groupes... bizarre.

Il m'est avis que ton truc est trop spécifique pour pouvoir trouver un plugin qui le fasse... donc il va falloir partir de bhLDAPAuthPlugin pour s'inspirer au niveau de la connexion. Il faudra aussi travailler sur sfDoctrineGuard en partie.

L'administration des droits ne va pas être simple, sauf à passer uniquement par des groupes, si non, tu vas devoir gérer, en local, le nom des users, en plus du nom des groupes que tu utilises et les droits à associer...

Je pense que le plus simple serait de partir de sfDoctrineGuard et de le modifier :
- Vérification de l'existence sur le serveur de l'user, puis du user dans les tables local et le cas échéant, l'insérer.
- Vérification des groupes de l'utilisateur sur l'autre serveur par une requête SQL, puis mise a jour en fonction des groupes existants sur ton application des liaisons utilisateur <-> groupes.
- le reste devrait pouvoir fonctionner comme sfDoctrineGuard fonctionne actuellement.
Il faut gérer les groupes en local, pour pouvoir leur attribuer des droits.
Il faut gérer les utilisateurs en local, pour pouvoir leur attribuer des droits individuels.

Ceci devrait pouvoir tourner.

Bonne chance.
Michel
PS1: Michel dit : "Je ne pense pas que surcharger la méthode soit une bonne solution", il n'y a que les imbécile qui ne changent pas d'avis !
PS2: nawbacan dit : "je connaissai pas le concept de table d'attente", tant mieux, c'est le genre de choses qui ne devrait pas exister dans l'authentification (mais j'ai déjà vu...).
17/08/2010, 10h03
nawbacan
Citation:
Envoyé par mimi68

Pour l'authentification LDAP il existe un plugin (jamais testé par moi) qui permet de gérer les connexions bhLDAPAuthPlugin il peut servir tel quel ou d'inspiration...

Ce qui m'étonne plus est le fait de valider le login sur LDAP et les groupes par une requêtes sur une table sql autre... LDAP est capable de gérer des user et leurs groupes... bizarre.

Il m'est avis que ton truc est trop spécifique pour pouvoir trouver un plugin qui le fasse... donc il va falloir partir de bhLDAPAuthPlugin pour s'inspirer au niveau de la connexion. Il faudra aussi travailler sur sfDoctrineGuard en partie.

L'administration des droits ne va pas être simple, sauf à passer uniquement par des groupes, si non, tu vas devoir gérer, en local, le nom des users, en plus du nom des groupes que tu utilises et les droits à associer...

Je pense que le plus simple serait de partir de sfDoctrineGuard et de le modifier :
Vérification de l'existence sur le serveur de l'user, puis du user dans les tables local et le cas échéant, l'insérer.
Vérification des groupes de l'utilisateur sur l'autre serveur par une requête SQL, puis mise a jour en fonction des groupes existants sur ton application des liaisons utilisateur <-> groupes.
le reste devrait pouvoir fonctionner comme sfDoctrineGuard fonctionne actuellement.

Il faut gérer les groupes en local, pour pouvoir leur attribuer des droits.
Il faut gérer les utilisateurs en local, pour pouvoir leur attribuer des droits individuels.

Ceci devrait pouvoir tourner.

Bonne chance.
Michel
PS1: Michel dit : "Je ne pense pas que surcharger la méthode soit une bonne solution", il n'y a que les imbécile qui ne changent pas d'avis !
PS2: nawbacan dit : "je connaissai pas le concept de table d'attente", tant mieux, c'est le genre de choses qui ne devrait pas exister dans l'authentification (mais j'ai déjà vu...).
merci pour ta réponse très complète ! N'ayant jamais développé ni modifié de plugin, je vais m'y atteler.

ps : pour un premier projet en symfony, je pensais pas faire autant de choses
17/08/2010, 20h05
Michel Rotta

En soit, c'est très modulable.

Et tu peux faire appel à un intervenant, éventuellement, pour juste le module de connexion.

A partir de moment que c'est un fork de sfGuardDoctrine, tu dois pouvoir commencer le développement avec et n'insérer le plugin qu'en fin de développement, sans avoir à rien toucher d'autre. C'est un plus non négligeable.
18/08/2010, 09h38
nawbacan

Citation:

Envoyé par mimi68

En soit, c'est très modulable.

Et tu peux faire appel à un intervenant, éventuellement, pour juste le module de connexion.

A partir de moment que c'est un fork de sfGuardDoctrine, tu dois pouvoir commencer le développement avec et n'insérer le plugin qu'en fin de développement, sans avoir à rien toucher d'autre. C'est un plus non négligeable.

hello,

mes connaissances en symfony en symfony ne sont pas aussi poussées :?
J'ai commencé à modifier le plugin sfdoctrineguard, peut-'etre pas de la manière la plus clean. En l'ocurrence j'ai rajouté une fonction dans la fonction signin dans le fichier :
sfDoctrineGuardPlugin/modules/sfGuardAuth/lib/BasesfGuardAuthActions.class.php
qui me permet de controler la présence de l'utilisateur dans la bd externe et le cas échéant de récupérer ses groupes.
L'ennui c'est que je me rend compte qu'il y a un check dans la db local sur le user loggé. Je dois trouver ce check et ajouter le création du user juste avant si il existe pas en local et qu'il existe dans l'application externe.
19/08/2010, 00h08
nawbacan

hello,
je voulais par ce post te remercier Michel pour l'aide que tu m'a fournie dans ce thread. J'ai en effet réussi à modifier le plugin sfDoctrineGuard pour mes besoins (authentification ldap + connexion à une db externe avant le log dans l'applic symfony).

J'ai d'ailleurs appris certaines choses que j'avais un peu délaissée lors de mon apprentissage du framework (notamment le doClean dans le validateur).

Ceci est ma première expérience sur le framework. Il n'est pas facile d'accès. Mais je commence à prendre du plaisir et je commence à avoir un avis très positif sur l'outil (notamment par rapport à Zend).
19/08/2010, 16h39
Michel Rotta

C'est comme tout les outils, il faut apprendre à comprendre comment il a été pensé et comment ont va pouvoir l'utiliser, au mieux.

Cela demande un peu d'apprentissage.

Bonne chance pour la suite,
Michel Rotta
28/10/2010, 23h15
mantex

Citation:

Envoyé par Michel Rotta

Je ne pense pas que surcharger la méthode soit une bonne solution.

Perso, j'ai un menu qui n'affiche que les options pour lesquel une personne à des droits. Donc, un quidam qui déboule en admin à droit, dans le menu à l'option "logout", un point c'est tout ! :lol:

Si non, tu peux spécifier le module et l'acion à exécuter juste après le login.

Dans le executeApresLogin() tu tests l'utilisateur, si non, logout... Cela devrait marcher, proprement.

Tu trouves cette fonction ou ?
29/10/2010, 20h28
Michel Rotta

Tu peux paramètrer le module et l'action à exécuter après un login (voir la fin de la documentation du plugin), si non, il renvoie sur le module par défaut, action par défaut, c'est là qu'il faut placer le code.
29/10/2010, 21h22
mantex

Oui oui j' ai vu ça mais je ne suis pas sur de la destination.
31/10/2010, 15h07
Michel Rotta

Crée un module généric avec une action login.

Redirige le login sur generic/login.

Fait ton traitement avec un redirect (plutôt qu'un forward)
31/10/2010, 15h45
mantex

Oui j' ai pensé faire cela à un moment mais cela ne pose t il pas de problème si ce module n' est pas associé à un modèle de données (une table dans mon schéma) ?

dans ce cas il doit exister un paramètre pour indiquer la création d' un module simple sans relation particulière non ?
02/11/2010, 21h15
Michel Rotta

Il y a même une action pour ça :
symfony generate:module
02/11/2010, 21h23
mantex

Oui j' ai vu cela.

J ai donc généré un nouveau module 'postlogin' dans mon application backend.