Discussion :

[Madfrix]

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]

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]

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]

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]

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]

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