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.

[darthmower]

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

this fait référence à l'instance courante un élément static est le même pour toutes les instances de l'objet.

Gripsou

[Jonathan.b]

this fait référence à l'instance courante un élément static est le même pour toutes les instances de l'objet.

Gripsou

Histoire de continuer dans le HS, il est possible d'accéder à la classe static ou juste à une propriété static avec $this ?

[manuscle]

Juste un p'tit truc... comme ça
On peut désactiver le controle d'acl dans la fonction init() du controlleur ce qui a pour effet de désactiver les acl pour tout le controlleur...

Comment on peut faire pour désactiver les acl juste pour une action?

[darthmower]

Ce que tu veux faire ce n'est pas d'autoriser pour tout le monde l'accès à cette action?

[manuscle]

Non mais en fait, j'ai juste qu'à autoriser l'action à l'utilisateur 'invité' dans la classe ACL!

Autant pour moi...

[darthmower]

Non mais en fait, j'ai juste qu'à autoriser l'action à l'utilisateur 'invité' dans la classe ACL!

Autant pour moi...

C'est bien ce que je pensais

[Bakura]

Je me permets d'upper ce topic car j'ai quelques questions.

J'aime bien l'idée de mettre en session l'acl, toutefois il y a certaines choses que je ne comprends pas :

- Quelle est l'utilité de rendre la classe Singleton ? Typiquement (après évidemment ça peut changer), on aura tendance à vérifier les droits accès uniquement dans la fonction preDispatch, auquel cas on peut se contenter de créer un objet Acl_Session directement dans le constructeur, et de vérifier dans le constructeur si l'objet est déjà stocké en session, auquel cas on le récupère. Cela simplifie pas mal l'implémentation. Effectivement cela peut avoir l'effet pervers de créer l'Acl autre part, mais si on vérifie un minimum le code que l'on écrit ...

- D'autre part, j'ai un peu de mal à voir la différence entre un plugin et un helper dans le cas des contrôleurs. Comme je le comprend, dans le plugin, l'action n'a pas encore été dispatché, alors que dans le helper, l'action a déjà été dispatché vers le contrôleur et l'action demandée. Dans le cas d'un système d'authorisation, il me paraît bien plus logique d'utiliser un plugin car le plugin est appelé avant le dispatchage, non ?

J'arrive à quelque chose comme ça (en fait le système utilisé d'habitude, si ce n'est que mon système d'Acl est mis en session).



(PS : la fonction getRole renvoie un objet qui implémente l'interface Zend_Acl_Role_Interface ou 'guest' si hasIdentity de Zend_Auth renvoie faux, comme dans l'article).

D'ailleurs, d'un point de vue performance, est-ce que cela se justifie vraiment ? Je veux dire, la création de l'ACL (visiblement implémenté sous un arbre binaire) est-elle si lente que ça pour qu'on souhaite la créer une seule fois ? A partir de quel moment la création devient pénalisante ?

EDIT : oops, un ArrayAccess qui s'est trompé de photo .

[manuscle]

J'espère que je dit pas de bêtise....

Mais selon moi, l'acl en singleton te permet d'avoir un seul et même gestionnaire d'acl pour contrôler tout tes accès, je pense que tu comprendra l'utilité à l'usage, c'est à dire quand tu aura plein de modules/controlleurs dans tout les sens.

Sinon, un plugin te permet en quelque sorte de "court-circuiter" le système et de réaliser des taches à n'importe quel moment de ton application.
Alors que l'aide d'action est appelée lors d'une action dans un contrôleur, donc a un moment plus précis...

[Bakura]

Mais selon moi, l'acl en singleton te permet d'avoir un seul et même gestionnaire d'acl pour contrôler tout tes accès, je pense que tu comprendra l'utilité à l'usage, c'est à dire quand tu aura plein de modules/controlleurs dans tout les sens.

Ha mais t'inquiète pas, je comprends tout à fait l'usage des singletons . C'est juste que dans ce cas là, je n'en vois pas l'utilité étant donné qu'en toute logique, seul notre plugin a besoin d'utiliser l'ACL.

Sinon, un plugin te permet en quelque sorte de "court-circuiter" le système et de réaliser des taches à n'importe quel moment de ton application.
Alors que l'aide d'action est appelée lors d'une action dans un contrôleur, donc a un moment plus précis...

Justement, ce qu'on souhaite ici c'est bien court-circuiter le plus vite possible afin de pouvoir rerouter l'utilisateur vers un autre contrôleur/action s'il n'a pas les accès possibles ?

[manuscle]

Ha mais t'inquiète pas, je comprends tout à fait l'usage des singletons . C'est juste que dans ce cas là, je n'en vois pas l'utilité étant donné qu'en toute logique, seul notre plugin a besoin d'utiliser l'ACL.

Pas forcément, dans mon cas justement j'utilise une application modulaire avec plusieurs bootstrap. Chaque bootstrap a besoin de récuperer l'instance d'acl pour ajouter ses propres accès donc c assez pratique du coup d'avoir un singleton. C'est que dans le tuto il utilise une seule classe qui ajoute les ressources libraire, admin etc.... Mais si ces ressources se trouvent à plusieurs endroits, c'est préférable d'utiliser cette méthode. Après niveau performances je ne suis pas assez callé pour te dire si vraiment ça va plus vite...
J'utilise aussi une aide de vue qui me permet d'afficher certains trucs en fonction des droits, là aussi l'aide récupère le singleton...
Une aide d'action peux aussi effectuer une action selon si t'es libraire ou utilisateur ou admin....

Justement, ce qu'on souhaite ici c'est bien court-circuiter le plus vite possible afin de pouvoir rerouter l'utilisateur vers un autre contrôleur/action s'il n'a pas les accès possibles ?

Pas forcément...
Comme je disais ci-dessous tu pourrais avoir besoin un jour de créer des aides de vue qui affichent, pourquoi pas tel ou tel menu en fonction des droits.

Enfin bref, les acls ne sont pas là que pour faire le physionomiste à l'entrée d'une boite de nuit...

[Bakura]

Bien vu pour le singleton et les modules, j'y avais pas pensé !

[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.