Discussion :

[Invité]

Les ACLs sont souvent un casse-tête à gérer, du moins si on ne prend pas la peine de réfléchir à créer sa propre structure de gestion de celles-ci. Souvent dans nos applications, c'est toujours la même chose. Ici je vais présenter un système de gestion automatisé des ACLs.
Attention comme tout atelier : il donne une idée que j'ai et que j'utilise sur le coup, mais qui n'est pas forcément adapté à tous, et possède un certain degré de couplage qui pourra peut-être déplaire. Ca donne en revanche quelques idées de manipulations avec le Zend Framework.

http://julien-pauli.developpez.com/t...telier/aclmvc/

[Janitrix]

Je suis en train de le lire, et c'est exactement ce que je recherchais, étant en prise avec l'automatisation et la gestion des ACLs. Encore une fois, rédaction claire, précise, et sujet maitrisé

Merci beaucoup m'sieur

[manuscle]

Très bien fait et vraiment souple ce tuto!

[Jonathan.b]

Bonjour,

Je viens de lire ce tuto qui donne pas mal d'idée pour la gestion des ACLs.

J'ai une première question (mais qui, je pense, n'a rien à voir avec le ZF).
Quelle est le principe du "self::" ? C'est comme un "this->" mais pour une accéder à une propriété static ?

Ensuite, une autre question en lien direct avec le tuto.
Dans ton exemple, tous les controllers sont des ressources et par défaut, le controller est interdit s'il n'existe pas dans l'acl.
Cela veut donc dire que lorsque l'on créer un nouveau controller, il faut automatique le rajouter à la liste des ressources ? (Il me faut juste une confirmation pour que je sois sure d'avoir tout compris) Et la même chose pour les actions ?

Merci d'avance.

[darthmower]

Salut,

<HS>
self fait référence au nom de class lui même, pour pouvoir appeler les méthodes, attributs statics en faisant abstraction du nom (permet de changer le nom de class sans avoir à changer pour les éléments statics)
</HS>

Je suis un peu déçu qu'il n'aborde pas la mise en cache des ACLs, cela m'aurait intéressé grandement.

Gripsou

[Jonathan.b]

Salut,
<HS>
self fait référence au nom de class lui même, pour pouvoir appeler les méthodes, attributs statics en faisant abstraction du nom (permet de changer le nom de class sans avoir à changer pour les éléments statics)
</HS>

Ce n'est pas ce que fais $this-> ? Par contre, $this est peut être une référence à l'objet et non à la classe...

Je suis un peu déçu qu'il n'aborde pas la mise en cache des ACLs, cela m'aurait intéressé grandement.

C'est vrai que ca serait pas mal d'avoir juste un chapitre sur l'optimisation des performances. Avec une appli complexe et des droits dans tous les sens, les perfs doivent vite chuter.

[Bakura]

J'ai pensé à quelque chose, avec cette histoire de plugin et d'action helper.

Visiblement, les aides d'actions sont créés après la création du contrôleur et de l'action. On pourrait ainsi créer un aide d'action qui définit uniquement les rôles :

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
class Controller_Action_Helper_Acl extends Zend_Controller_Action_Helper_Abstract
	{
		private $_acl;
 
		// Constructeur (initialise les rôles)
		public function __construct ()
		{
			$this->_acl->addRole ('guest');
			$this->_acl->addRole ('member');
		}
 
		// Pre-dispatch
		public function preDispatch ()
		{
			// ...
			if ($this->_acl->isAllowed ($role, $actionController, $action))
				// ...
			else
				// ...
		}
	}

Puis dans la fonction init de chaque contrôleur, définir uniquement les actions considérées :

Code :

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

1
2
3
4
5
6
7
8
9
10
class TetsController extends Zend_Controller_Action
	{
		public function init ()
		{
			// Pas sûr des noms de fonction
			$this->_acl = $this->_helper->getHelper ('Acl');
 
			$this->_acl->add (// Les différentes actions de ce contrôleur);
		}
	}

En plus, les définitions des différentes ressources se font directement dans les contrôleurs et donc toutes les définitions de ressources ne sont pas "mélangées" dans un fichier, mais regroupées logiquement.

Qu'en pensez-vous ?

[MaitrePylos]

Ce qui veut dire que dans chaque controller tu dois gérer tes ACL, alors que le but justement n'est de ne plus s'en préoccuper!

[Bakura]

Juste la création. A vrai dire ça me paraît logique de gérer les autorisations d'un contrôleur donné. Directement en ouvrant le fichier du contrôleur, on peut voir dans la fonction init quelles actions sont autorisées et pour qui.

[MaitrePylos]

Oui, mais justement, les ACL, te permet de gérer tes controllers puisque ce sont tes ressources.

Maintenant si tu pars dans des considération..."oui mais cela prend de l'espace mémoire".

La grande force de ZF est de pouvoir faire de plusieurs façons.

Maintenant pose toi la question....si je crée un nouveau rôle, est-il plus facile de modifer un fichier ou tout mes controllers ?

[Bakura]

Bien vu le cas des ajouts d'un nouveau rôle =).

[manuscle]

Une approche un peu différente serait de gérer les rôles via une base de donnée.

C'est ce que j'ai fait et ça fonctionne assez bien.
En fait pour le système, un seule role existe, le role 'member'
La première fois qu'un utilisateur arrive sur le site et qu'il n'a pas de session, le helper le détecte et lui attribue les permissions correspondant à 'invité' stockées en base au rôle 'member'.

Lors de sa connexion, une méthode de mon modèle Model_User interroge la base pour connaitre quel(s) rôle(s) est attribué à l'utilisateur et met à jour les permissions en fonction au role 'member'.

Pour les ressources j'ai un peu abandonné l'idée de dire que chaque controlleur est une ressource et chaque action est une permission car je me suis aperçu que pas mal d'actions n'avaient pas besoin d'être une permission et qu'elles pouvaient être regroupées en un groupe de permission.

D'où l'idée de faire un fichier de config dans le module qui stocke en dur les ressources/permissions et leur définitions.
L'avantage c'est que j'ai un formulaire qui me permet de gérer les autorisations, il va chercher chaque fichier config de chaque module, récupère la liste des permission et me les affiche pour chaque groupe.
(cf. image jointe)

Dans chaque action je vérifie les droits par un helper.... ou pas.
Par exemple, la page 'contact' en général n'a pas be soin de droit.

Bon c'est juste une idée...