Discussion :

[nawbacan]

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

[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).

[nawbacan]

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.

[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 !

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.

[nawbacan]

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 !

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.

[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...

[nawbacan]

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.

[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.

[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...).

[nawbacan]

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

[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.

[nawbacan]

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.

[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).

[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

[mantex]

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 !

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 ?

[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.

[mantex]

Oui oui j' ai vu ça mais je ne suis pas sur de la destination.

[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)

[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 ?

[Michel Rotta]

Il y a même une action pour ça :
symfony generate:module