Plugins Zend Controller vs contrôleur d'action sous-classe

Question

J'ai un système ACL assez standard dans mon application. Un contrôleur de connexion et un tas d'autres contrôleurs redirigent vers la connexion si l'utilisateur n'est pas autorisé. J'utilise un Controller Plugin pour vérifier l'ID et la redirection et je ne veux évidemment pas que le contrôleur de connexion et le contrôleur d'erreur effectuent une telle redirection.

Maintenant, j'ai lu plusieurs fois que l'utilisation de Controller Plugins est une meilleure pratique que de sous-classer le contrôleur d'action. Pourtant, ce que je vois est qu'il est beaucoup plus facile d'étendre tous mes contrôleurs de cette classe de contrôleur de base abstraite qui effectue la vérification nécessaire dans sa méthode init, sauf pour le contrôleur de connexion qui étend Zend_Controller_Action directement. Donc, la question est, y at-il un moyen d'attacher le plugin aux contrôleurs de manière sélective? Bien sûr, je peux toujours faire un tableau de certains contrôleurs, l'envoyer à un plug-in à travers une méthode setter et faire quelque chose comme:

$controller = $request->getParam('controller'); 

if (count($this->exceptions)) 
    if (in_array($controller, $this->exceptions)) return; 

//...check ID, perform redirect, etc... 

Pourtant, quelque chose me dit que ce n'est pas la meilleure façon de le faire.

Et des conseils?

EDIT 1: @Billy ONeal

Merci pour votre réponse, mais je ne se coincent pas tout à fait. Je peux faire

public function init() 
{ 
    $this->getRequest()->setParam('dropProtection', true); 
} 

(ou exécuter une méthode qui définit une variable privée du plug-in) dans mon contrôleur de connexion, puis dire si « dropProtection » est pas vrai, alors vérifiez l'ID utilisateur. Mais le processus d'expédition réelle ressemble à ceci:

Plugin::dispatchLoopStartup 
Plugin::preDispatch 
Controller::init 
Plugin::postDispatch 
Plugin::preDispatch 
Plugin::postDispatch 
Plugin::dispatchLoopShutdown 

donc je ne peux pas vérifier param « dropProtection » plus tôt que dans le plugin :: postDispatch et c'est un peu en retard. (en passant, pourquoi le preDispatch et postDispatch sont appelés deux fois?)

Answer 1

Si vous voulez le faire plus tôt, je pense que vous pouvez utiliser la première méthode (passer un tableau d'exceptions au plugin) et tester le nom du module ou le nom du contrôleur dans routeShutdown.

Personnellement, j'utilise une aide d'action pour vérifier l'auth dans toutes mes actions. C'est plus flexible et donne plus de contrôle. C'est seulement une ligne pour chaque action privée.

Et NE SUBCLASS votre contrôleur d'action. Je l'ai fait sur un de mes projets et maintenant ma classe de base est une merde. Utilisez action helper à la place.

Answer 2

Y at-il un moyen d'attacher le plugin aux contrôleurs de manière sélective?

Bien sûr. Il suffit de ne pas enregistrer le plugin si la requête ne contient pas les paramètres que vous recherchez. Alternativement, supposons que toutes les pages sont protégées, et ont ces pages qui ne devraient pas être protégées appelez une méthode sur votre plugin au cours de l'étape init.

Si vous souhaitez protéger un seul contrôleur, vous pouvez inverser cela - faire en sorte que le plugin n'agisse que s'il y a une méthode appelée pendant la phase d'initialisation. Enfin, vous pouvez créer la section complète de la page de son propre module, ce qui vous permettrait de vérifier le plugin pour ce module avant de vérifier les informations d'identification et de les rediriger.