Où mettre les ACL ?

**Madfrix** · 31/07/2010, 11h38

Bonjour,

sur pas mal de sites, je vois qu'il est recommandé de ne pas mettre ses acl dans une classe mais plutôt dans un fichier ini, à chaque fois sans plus d'informations quant à ce choix...

Ex:

Je vous propose ci-dessous un exemple de classe qui permet la gestion de droit dans un fichier INI. Libre à vous d'imaginer comment charger ces droits depuis une base de données ou autres. Vous pouvez également définir les droits directement dans la classe, mais ça, je ne saurais vous le conseiller.

J'ai donc 2 questions :

1) où est il préférable de mettre ses acl ?
2) impact de performances possible si on les met dans un fichier ini (parsage du fichier a chaque nouvelle url car acl invoquée dans un plugin méthode predispatch()) ?

Merci

**freeseb74** · 31/07/2010, 12h22

Bonjour,

Je n'ai pas de réponse exacte à te donner, tout dépend de ton application et de l'organisation dont tu veux mener autour des droits d'accès, je pense qu'il faut être en adéquation entre ton organisation dans ton code et l'évolution futur de ton application pour être flexible.

Je te donne mon expérience sur un projet Intranet assez important :
- Beaucoup d'utilisateur hétérogène sur les droits d'accès (utilisateur à la fois utilisateur et contributeur de nouvelles données)
- Gestion du menu personnalisé en fonction des droits d'accès pour chaque utilisateur
- Permettre l'évolution de l'application (nouveau controller) sans remettre en cause la gestion des droits d'accès.
- une interface pour gérer les nouveaux controller et action, le menu, et les droits d'accès.

Pour ceci j'ai mis toutes mes données en base de données, dont voici le MCD en pièce jointes.

Pour le code je me suis basé sur le tutos de Julien Pauli
Atelier Zend Framework : Créer une simple authentification HTTP, avec rôles

Dans le principe via une interface je pouvais (informer ma base) :
- Ajouter des nouveaux controller
- Ajouter des nouvelle action
- créer une ressource = Controller + action
- Créer une arborescence pour mon menu
- Lier un élément du menu à une ressource
- Attribuer une ou plusieurs ressources à un utilisateur.
- pouvoir dupliquer les droits (ACL) d'un utilisateur sur l'autre
- Possibilité de réorganiser le menu sans toucher au droits d'accès de chaque utilisateur.

Voilà pour mon expérience.
Pour me critiquer :
- Avantage une forte granulité dans les droits d'accès jusqu'à l'action d'un controller
- Inconvénient un formulaire (automatique) avec autant de ressource pour donner les droits d'accès.

**Madfrix** · 31/07/2010, 13h00

Merci de ton feedback Sébastien.

Je compte créer pour me familiariser avec Zend et ses principaux modules, un forum avec différents rôles (invite, membre, moderateur, admin,...). Ainsi, dans mon cas de figure, c'est à priori un cas relativement simple et rigide où il n'est pas possible de créer de nouvelles ressources une fois mon architecture établie (ou très peu).

Il en résulte donc des acl assez simples donc je pense exclure d'emblée un stockage en base (lourdeur des traitements, intérêt moindre dans mon cas). Reste le stockage "en dur" dans une classe ou fichier (ini, xml). Je partirai plus sur le stockage en classe qui à priori me semble plus rapide que de parser un quelconque fichier. Cependant, comme je l'ai écris plus haut, je vois régulièrement que le stockage en classe est déconseillé mais je n'ai jamais trouvé de raison associée à cette "délation"...

**freeseb74** · 31/07/2010, 16h06

Madfrix,

Tous mes encouragements pour ta quête, il est vrai qu'il faut adapter son code en fonction du type de fonctionnement et du degré de flexibilité que l'on exige de l'application.

Par exemple pour un site perso, ou je suis le seul administrateur, j'ai simplement rajouté dans mes routes un paramètre 'access' = (public | admin) car j'utilise URL Rewriting, un paramètre qui est intercepté par un plugin controller pour me rediriger vers un formulaire d'authentification quand param access=admin dans la requête.

Je n'ai jamais été confronté à ton cas ou quelques rôles sont définies, cela me donne l'occasion d'y réfléchir sur le type d'implémentation. Mais lorsque tu auras commencé le sujet, n'hésite pas pour d'autres questions.

**manuscle** · 01/08/2010, 23h16

Bonjour,

Par expérience, je préfère utiliser une classe de configuration pour gérer les acls. Les sites sont crés de façon modulaire, donc, chaque module possède sa propre classe d'acl.
Je préfère une classe car il m'est possible d'y regrouper les définitions et de pouvoir les traduire automatiquement car j'utilise gettext et poedit, en voici un exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
<?php
class User_Model_Config extends Ez_Config_Module implements Ez_Config_Module_Interface
{
    public static function getResourcesDef()
    {
        $ressources = array(
            // module
            'user' => array(
                'title' => self::translate("Utilisateurs"),
                'description' => self::translate("Administrer les utilisateurs"),
                'admin_privileges' => array('admin_index:index','user_admin:index','user_admin:list'),
                // module_controller[action]
                'resources' => array(
                    'user_admin'    => array('view'   => array('description' => self::translate("Voir les utilisateurs"), 'admin' => true),
                                             'edit'   => array('description' => self::translate("Editer un utilisateur"), 'admin' => true),
                                             'delete' => array('description' => self::translate("Supprimer un utilisateur"), 'admin' => true)),
 
                    // Droits de l'utilisateur sur ses propres adresses
                    'user_address'  => array('list' => array('description' => self::translate("Voir son carnet d'adresses"), 'admin' => false),
                                             'edit' => array('description' => self::translate("Editer son carnet d'adresses"),  'admin' => false)),
 
                    // Droits de l'utilisateur sur les adresses en administration
                    'admin_address' => array('list' => array('description' => self::translate("Voir les adresses utilisateurs"),    'admin' => true),
                                             'edit' => array('description' => self::translate("Editer des adresses utilisateurs"),  'admin' => true)),
 
                    // Profil utilisateur
                    'user_profile' => array('index' => array('description' => self::translate("Accéder à son compte"), 'admin' => false),
                                            'edit' => array('description' => self::translate("Editer son compte"), 'admin' => false),
                                            'subscribe' => array('description' => self::translate("Se créer un compte"), 'admin' => false)),
 
                    'user_roles' => array('view' => array('description' => self::translate("Voir les roles des utilisateurs"), 'admin' => true))
                    /**
                     * Pour infos : Seul un super administrateur peut gérer les rôles et les attribuer à des utilisateurs
                     */
            ))
        );
 
        return $ressources;
    }
}

Déjà j'ai 2 niveaux d'acl:
- le droit à l'administration du site (admin = true)
- le droit à l'utilisation du site (admin = false)

Au début je gérait un droit par module/controller/action via plugin comme un tuto de ce site mais c'est vite devenu lourd car certaines actions peuvent etre englobées dans un seul et même droit. J'ai donc préféré un helper dans chaque action qui vérifie le droit.
Si une action ne nécessite pas de droit il suffit de ne pas appeler le helper et c'est tout.

Je crée une fois l'acl et l'enregistre en session, ensuite dans chaque bootstrap de chaque module je charge le fichier de config dans l'objet d'acl si c'est pas déjà fait.
De plus, je n'utilise que deux role en dur: user et guest.
Les roles sont gérés par le SGBD, j'ai une table 'roles' avec le nom du role et les privilèges associés et une table qui relie l'utilisateur au role.
Tout les utilisateurs on le role guest par defaut. A la connexion, l'utilisateur prend le role user et ses autorisation sont chargées dans l'acl...

Cette methode fonctionne en production et je n'ai pour le moment aucun soucis. De plus elle peut etre employée sur des sites à plus ou moins grosse envergure.
Si tu veux en savoir plus n'hésite pas.

**Madfrix** · 02/08/2010, 00h14

Envoyé par manuscle

Au début je gérait un droit par module/controller/action via plugin comme un tuto de ce site mais c'est vite devenu lourd car certaines actions peuvent etre englobées dans un seul et même droit. J'ai donc préféré un helper dans chaque action qui vérifie le droit.
Si une action ne nécessite pas de droit il suffit de ne pas appeler le helper et c'est tout.

J'ai pas trop saisi ce point là : pourquoi est ce plus rapide de gérer un droit par le helper que par la classe ?
Si j'ai 10 actions (action1, action2 etc...) sur mon controller monController avec les action 4 et 9 refusées pour le rôle user je peux faire ceci non ?

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$this->allow('user', 'monController');
$this->deny('user', 'monController', array('action4', 'action9'));

Enfin, je me suis fais un petit site avec 3 rôles et des autorisations/authentifications basées sur ce mode de fonctionnement et ca a l'air de marcher (dis moi si je me trompe...^^).

J'ai aussi une seconde question : tu parles de mettre tes acl en session mais quel est l'avantage par rapport à gérer les acl dans un plugin (predispatch) ? Ou alors est ce déjà ce que tu fais ? J'ai peut être mal saisi...

Merci de tes éclaircissements

**manuscle** · 02/08/2010, 10h39

Envoyé par Madfrix

J'ai pas trop saisi ce point là : pourquoi est ce plus rapide de gérer un droit par le helper que par la classe ?
Si j'ai 10 actions (action1, action2 etc...) sur mon controller monController avec les action 4 et 9 refusées pour le rôle user je peux faire ceci non ?

Code php :

$this->allow('user', 'monController');
$this->deny('user', 'monController', array('action4', 'action9'));

Enfin, je me suis fais un petit site avec 3 rôles et des autorisations/authentifications basées sur ce mode de fonctionnement et ca a l'air de marcher (dis moi si je me trompe...^^).

J'ai aussi une seconde question : tu parles de mettre tes acl en session mais quel est l'avantage par rapport à gérer les acl dans un plugin (predispatch) ? Ou alors est ce déjà ce que tu fais ? J'ai peut être mal saisi...

Ce n'est pas plus rapide, c'est juste à mon gout plus pratique et ton code fonctionne très bien! Je te présente juste une façon différente de concevoir les acls. Pour faire cette strategie, je me suis inspiré du bouquin de Julien Pauli et j'aime bien l'exemple qu'il donne dans le livre.

C'est juste que le plugin predispatch m'impose le fait qu'une action est forcément un droit à donner. Hors si j'ai deux actions qui sont similaires je suis tout de même obligé de donner l'autorisation pour chacune des deux actions dans la console d'admin. Et plus le site grandit plus je me retrouve avec des autorisations à donner qui sont un peu inutiles et qui peuvent être regroupées. Un exemple simple:

Dans mon UserController, j'ai ces deux actions: listAction() et detailAction(), ces deux actions correpondent au droit 'view' de mon fichier de config qui veut dire 'voir les utilisateurs'. (Je pars du principe que si j'ai le droit de voir la liste des utilisateurs, j'ai aussi le droit de voir les details d'un utilisateur). 'view' est donc un namespace, je n'ai pas de viewAction() dans mon controlleur. Au final, ça réduit de moitié le nombre de droits à attribuer dans l'admin.

Ensuite, dans chaque action je fait ceci:
$this->_helper->aclCheck('user_admin', 'view');

Le helper interroge l'acl en session et redirige le user sur une 403 si il n'a pas le droit.

Aucune regle de droit n'est défini dans les classes de mon application, à aucun moment dans un bootstrap ou autre je fait $acl->deny('user', 'monController', array('action4', 'action9')); Ce qui fait que lors de l'initialisation de Zend_Acl, tout est interdit par defaut.
Les droits sont donnés lors de l'authentification(user) ou lors de la création de session(guest), j'ai une methode setAcl qui interroge la base et qui ne fait qu'autoriser les droits qui auront été cochés en administration.

Le fait de stocker l'objet d'acl en session vient aussi du bouquin de Julien Pauli. Cela permet de ne pas avoir à recréer les acls et redonner les droits à chaque chargement de page. C'est adapté à mon système d'acl. Un objet d'acl est donné pour chaque session et les droits y sont stockés le temps de la session une bonne fois pour toute.

Wow, c'est compliqué d'expliquer tout ça! Désolé si je me fait mal comprendre!
Zend_Acl est vraiment très souple, tu peux vraiment faire comme ça t'arrange.
C'est sûr que si ton site contient très peu de droits, mon idée n'est pas forcément idéale...

**Madfrix** · 02/08/2010, 11h19

Envoyé par manuscle

Wow, c'est compliqué d'expliquer tout ça! Désolé si je me fait mal comprendre!

Non c'est cool au contraire, merci de prendre le temps de m'expliquer. Cela m'a fait comprendre qu'on pouvait ne pas mettre des acl sur chaque action, chose que je ne croyais pas possible (enfin j'avais pas testé).

Pas mal aussi le coup du helper, je commence à en voir l'intérêt

Envoyé par manuscle

Aucune regle de droit n'est défini dans les classes de mon application, à aucun moment dans un bootstrap ou autre je fait $acl->deny('user', 'monController', array('action4', 'action9')); Ce qui fait que lors de l'initialisation de Zend_Acl, tout est interdit par defaut.

Tu veux dire plutôt que lors de l'initialisation de Zend_Acl, tout est autorisé par defaut plutôt non ? Sans acl sur une action, l'action est allow ou deny ?

EDIT: exact sans autorisation explicite, l'action est bien deny...

**manuscle** · 02/08/2010, 12h23

Normalement toute action devrait avoir un acl..... Mais dans les projets que je développe, certaine pages statiques sont publiques comme le formulaire de contact ou la page 'about'. Finalement y en a pas tant que ça...

En tout cas j'aime l'idée de décider si une action doit être contrôlée ou pas.

**gredey** · 22/02/2014, 12h56

slt je suis sur un projet zend ou j'ai une interface ou on peut affecter et retirer des ressources aux utilisateurs.J'ai une une tablement traitement ou tous les ressources sont enregistrées et une table traitementgroupe ou les j'enregistre les ressources de chaque groupe.Donc j'aimerais charger mes ressources et mes roles depuis la base de donnée mais je sais pas comment faire

Où mettre les ACL ?

Zend_Acl & Zend_Auth PHP

Discussions similaires

Partager

Partager