Discussion :

[vvm]

Bonjour à tous,
Je développe actuellement un site web contenant plusieurs modules de cette forme là :
/controller/action
....
/module1/controller/action
....
/module2/controller/action
....

je souhaiterai implémenté le module ACL (control d'accès) du Framework, mais je ne sais pas comment faire ça de façon optimal et propre.

merci à vous.

[goodpz]

Bonne question.

Je n'ai pas encore utilisé Zend_Acl en production (c'est à dire sur ma machine en local ; )

Que voudrais-tu définir en tant que Resource ? module+controller, controller seul , ou d'autres choses ? Il faudrait que tu nous expliques un peu plus en détail ce que ferait un tel système de contrôle d'accès dans ton application.

Tuto: Zend_Acl / Zend_Auth example scenario http://devzone.zend.com/node/view/id/1665
Dans ce tuto, les Resources sont simplement mappées par rapport aux controllers et sont déclarées avec Zend_Acl_Resource (alors qu'on pourrait imaginer des controllers qui implémenteraient directement Zend_Acl_Resource_Interface). Même chose pour Les privilèges, ils correspondent directement aux actions (fonctions) du controller.

Utiliser cette technique dans le cadre d'une application avec module pourrait revenir à déclarer les Resources comme combinaisons de 'module+controller'. Ensuite, il n'y aurait pas de changement..

[vvm]

Mon application est défini sur 3 niveaux :
- module
- controller
- action
Et je souhaiterai controller l'accès de chacun de ses niveaux.

Ton idées est pas mal concernant la fusion du module + controller pour les définir en tant que ressource. (je testerai cette après midi)

Ou sinon, je pensais créer une classe qui se chargerai d'instancier la classe ACL spécifique à chaque module (MyACL dans le tuto), puis de fonctionner comme dans le tuto http://devzone.zend.com/node/view/id/1665. (à étudier quand j'aurais le temps).

[Yoteco]

J'ai exactement le même problème que vvm! Mon appli a exactement la même structure.

Moi je suis entrain de développer un CMS et je dois limiter l'accès à certains modules par utilisateur et à certaines fonctions (delete, create, edit, read). J'ai lu ce tuto au moins 10 fois mais je ne vois pas comment l'utiliser dans mon cas.
Je devrais stocker les différents droits d'accès dans une base de données avec les groupes et les utilisateurs qui appartiennent à un ou plusieurs groupes...

Apparement Zend_Acl gère tout sa mais je n'y arrive pas. Si vous avez du nouveau postez ici !!!!

[goodpz]

Mon application est défini sur 3 niveaux :
- module
- controller
- action
Et je souhaiterai controller l'accès de chacun de ses niveaux.

Puisque le contrôle doit pouvoir s'opérer sur chaque niveau (3 couches), alors il serait probablement plus judicieux de déclarer une hiérarchie de resources plutôt que d'utiliser une approche linéaire:

Chaque module est une resource et chacun de ces controllers est une resource fille (donc les règles sont héritées). Dans le code, c'est simple, il faut juste passer le parent en 2ième paramètre de Zend_Acl::add().

Je pense que la technique du tuto (cf précédents posts) qui consiste à utiliser un plugin pour valider les droits est pas mal car ça laisse le code des controllers inchangé. La question c'est où et comment déclare-t-on les resources, les roles et les rules.

Une solution ça serait de créer une Factory de Zend_Acl (tu as plus ou moins la même idée vvm). Dans le plugin, lors du preDispatch() quand on connait le module et le controller sur le point d'être appelés, on rapatrie une instance de Zend_Acl (module specific).

Y a un inconvénient avec ce design c'est que le Zend_Acl spécifique au module ignore tout du reste puisqu'il est créé de toute pièce dans le preDispatch(). Quid des resources/roles généraux à l'application ? Par exemple, les roles 'guest' ou 'admin' ne devraient pas être créé par le module, mais en amont et le module va les utiliser pour déclarer ses propres rules. Du coup une solution ça serait non pas d'utiliser un Factory mais un Builder de Zend_Acl:

Relativement tôt dans l'application, on créé un Zend_Acl dans lequel on déclare les resources/roles/rules généraux. On passe cette instance au plugin qui va à son tour la passer à un Builder d'acl modul specific. D'où probablement l'usage d'un Factory de Builder. Le Builder va retourner le Zend_Acl initial mais augmenté des nouvelles resources/roles/rules du module. Ensuite le plugin va pouvoir checker les droits et faire son job.

Je devrais stocker les différents droits d'accès dans une base de données avec les groupes et les utilisateurs qui appartiennent à un ou plusieurs groupes

Zend_Acl ne fournit pas d'interface pour automatiser la persistance ou rapatrier les données de systèmes externes. Je ne pense pas que ce soit un problème, il suffit juste de faire son propre système (donc par exemple rapatrier les roles de la db et configurer un Zend_Acl). Comme il y a potentiellement des hiérarchies de roles, il faut que le schema de la db soit adapté. Par contre il est prévu que Zend_Auth ait différents storage adapters.

[Invité]

Puisque le contrôle doit pouvoir s'opérer sur chaque niveau (3 couches), alors il serait probablement plus judicieux de déclarer une hiérarchie de resources plutôt que d'utiliser une approche linéaire:

Chaque module est une resource et chacun de ces controllers est une resource fille (donc les règles sont héritées). Dans le code, c'est simple, il faut juste passer le parent en 2ième paramètre de Zend_Acl::add().

Entièrement d'accord, je suis parti sur la même base de réflexion pour un plugin de gestion des ACL.

Il faut définir les éléments racines par rapport à l'application, en l'occurence il s'agit des modules.

L'élément "racine" est donc le module et toutes les régles sont héritées de celui-ci (du général au particulier).

Le stockage des ACL peut être définit "en dur" dans un plugin si l'application est relativement petite et n'a pas vocation à évoluer, c'est le cas dans le tutoriel de Simon Mundy.

Pour ma part j'ai choisi une solution plus fléxible et dynamique en utilisant une base de données pour stocker les ACL. Je me suis à la base inspiré de cet article.

J'ai également dynamisé le concept de rôles ACL aux utilisateurs (de manière individualisée) ainsi qu'aux groupes d'utilisateurs de mon application.

De cette manière j'ai obtenu une gestion des ACL dont les bases ressemblent à celle d'un système d'exploitation.

Rien n'empêche d'aller plus loin !

[jeyaram]

Moi je suis entrain de développer un CMS et je dois limiter l'accès à certains modules par utilisateur et à certaines fonctions (delete, create, edit, read). J'ai lu ce tuto au moins 10 fois mais je ne vois pas comment l'utiliser dans mon cas.
Je devrais stocker les différents droits d'accès dans une base de données avec les groupes et les utilisateurs qui appartiennent à un ou plusieurs groupes...

Apparement Zend_Acl gère tout sa mais je n'y arrive pas. Si vous avez du nouveau postez ici !!!!

Je suis egalement en train d'utiliser Zend_Acl pour limiter les acces. J'ai plusieurs actions :
- Ajouter (un etudiant)
- Supprimer
- Editer (des infos sur l'etudiant)
- et bien d'autres

Les actions Ajouter/Supprimer/Editer/ etc... ne peuvent etre effectue seulement par l'admin, alors qu'un etudiant ne pourra que consulter les infos (sur tout le mode), ou bien il pourra modifier les infos le concernant SEULEMENT APRES une Authorisation.

Je n'ai pas encore trouve comment je peux gerer ca, auriez-vous une idee ?

Yoteco, as-tu reussi a te debrouiller ?

Merci

[Yoteco]

Ben en fait une solution assez simple est de dire que chaque module est une ressource et chaque controller est une autre ressource qui hérite des droits du module... Et sa marche