Zend_Acl avec plusieurs modules

Version imprimable

12/03/2007, 16h34
vvm

Zend_Acl avec plusieurs modules

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.
12/03/2007, 17h22
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..
13/03/2007, 09h27
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).
13/03/2007, 10h27
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 !!!!
13/03/2007, 16h13
goodpz

Citation:

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.

Citation:

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.
01/05/2007, 18h51
jeyaram

Citation:

Envoyé par Yoteco

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
03/05/2007, 20h15
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 ;)
05/09/2007, 14h33
scramatte

Quelqu'un aurai t'il une solution concrete avec code a l'appui pour gerer
ACL a 3 niveaux ?

- module
- controller
- action
30/10/2007, 09h21
vallica

Bonjour à tous,

Je suis en train d'apprendre le Zend Framework et je cherche aussi à implémenter un contrôle d'accès sur module/controleur/action.

L'un d'entre vous aurait réussi et pourrais me donner la démarche à suivre ?

Merci d'avance.
30/10/2007, 09h50
Yoteco

Salut,

J'ai fais une traduction d'un article sur Zend_Acl ici

Salut,

Je suis tombé sur ton tutoriel, j'ai voulu le mettre en œuvre mais j'ai été bloqué à plusieurs endroits :

- J'ai l'impression qu'il ne gère pas les modules, tu es dans un contexte controleur/action

- Je n'ai pas compris le sens de cette ligne :

Code:

1
2
3
// Ajout d'un nouvel objet ACL
        $this->allow('member', 'forum', 'update', new MyAcl_Forum_Assertion($auth));
        // NOTE: Zend_Acl dépend de Zend_Auth, il faut toujours lui passer en paramètre pour obtenir l'identité

- Dans le chapitre "II-C. Auth.php" le code de la classe est tronqué, j'ai l'impression qu'il manque la fin.

EDIT :

Je viens de me pencher à nouveau sur ton tuto et voilà encore une erreur qui m'a freiné dès le début du tuto lorsque l'on déclare les rôles.

L'erreur est

Code:

Fatal error: Can not call constructor in F:\www\zend\index.php on line 36

et voici mon index.php :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
<?php
error_reporting(E_ALL|E_STRICT);
 
date_default_timezone_set('Europe/Paris');
 
include "Zend/Loader.php";
Zend_Loader::loadClass('Zend_Controller_Front');
Zend_Loader::loadClass('Zend_Config_Ini');
Zend_Loader::loadClass('Zend_Registry');
Zend_Loader::loadClass('Zend_Db');
Zend_Loader::loadClass('Zend_Db_Table');
// auth
Zend_Loader::loadClass("Zend_Auth");
Zend_Loader::loadClass("Zend_Auth_Result");
Zend_Loader::loadClass("Zend_Auth_Adapter_Interface");
Zend_Loader::loadClass("Zend_Acl");
 
// Chargement du fichier ini de config
$config = new Zend_Config_Ini('./application/config.ini', 'general');
$registry = Zend_Registry::getInstance();
$registry->set('config', $config);
 
// setup database
$db = Zend_Db::factory($config->db->adapter,  $config->db->config->toArray());
Zend_Db_Table::setDefaultAdapter($db);
Zend_Registry::set('dbAdapter', $db);
 
// Create auth object
$auth = Zend_Auth::getInstance();
 
// Create acl object
class MyAcl extends Zend_Acl
{
    public function __construct(Zend_Auth $auth)
    {
        parent::__construct();
 
        $this->add(new Zend_Acl_Resource('niveau1'));
        $this->add(new Zend_Acl_Resource('niveau2'));
 
    	// le rôle superviseur aura accès au module nommé Niveau1
        $this->addRole(new Zend_Acl_Role('superviseur'));
        $this->allow('superviseur', 'niveau1');
 
        // le rôle coordinateur aura accès au module nommé Niveau2
        $this->addRole(new Zend_Acl_Role('coordinateur')); 
        $this->allow('coordinateur', 'niveau2');
 
        // le rôle admin donne accès à tout
        $this->addRole(new Zend_Acl_Role('admin')); 
        $this->allow('admin');
    }
}
$acl = new MyAcl($auth);
 
// setup controller
$frontController = Zend_Controller_Front::getInstance();
$frontController->throwExceptions(true);
 
$frontController->setControllerDirectory(array(
		'default' => 'application/modules/default/controllers',
		'niveau1' => 'application/modules/Niveau1/controllers'	
));
 
//$frontController->addModuleDirectory('application/modules');
 
// run!
$frontController->dispatch();

30/10/2007, 17h34
vallica

Ca y est j'ai réussi à faire tourner ton tuto moyennant quelques petites modifications, par contre j'ai un dernier souci.

Comment intégrer facilement la définition des ACL en prenant en compte une architecture à 3 niveaux (module/controlleur/action) alors que par défaut la vérification se fait sur controlleur/action ?
30/10/2007, 19h45
Yoteco

Il me semble qu'une solution serait de définir un module comme ressource et les contrôleurs du modules héritent de cette ressources au niveau des droits...

Mais je n'ai jamais mis ceci en place!

Dit en passant ce n'est pas "mon" tutoriel mais celui de Simon Mundy je n'ai fais que traduire moi 8-)
30/10/2007, 21h23
vallica

J'ai essayé ca ne fonctionne pas sans un remaniement des contrôles que tu fais plus bas dans le plugin d'auth, car tu va utiliser la métode isAllowed qui ne prend que 3 paramètres.

Un début de solution que je n'ai pas terminé est de jouer sur le libellé de tes ressources en choississant une convention de nommage afin de controler l'accès au mieux dans le predispatch().

Si ca fonctionne je vous en ferais part.

++
30/10/2007, 21h39
Invité

Citation:

Envoyé par goodpz

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 !