Hi,
It's a good tutorial but we have some problems...
1- getinstance not exist in Zend_Auth, where is it ?
2- The good route controller is Zend_Controller_ModuleRewriteRouter and not Zend_Controller_RewriteRouter

Hi darby,

Well, good news :)
The Singleton approach is a good idea. Will this approach be operational for 0.8 or 0.9?

I am already registered on this mailing list. I missed this discution.

Hi there. Where would the code for the MyAcl class actually go? As in, where would you put the class file?

I'm also a bit vague on what the auth is actually looking at to check usernames and passwords.

Also, did your tutorial get cut off? It just sort of...ends...in the middle of your plugin code.

Here's the missing code! :-)

<?php

class My_Plugin_Auth extends Zend_Controller_Plugin_Abstract
{
private $_auth;
private $_acl;

private $_noauth = array('module' => 'default',
'controller' => 'login',
'action' => 'index');

private $_noacl = array('module' => 'default',
'controller' => 'error',
'action' => 'privileges');

public function __construct($auth, $acl)
{
$this->_auth = $auth;
$this->_acl = $acl;
}

public function preDispatch($request)
{
if ($this->_auth->hasIdentity()) {
$role = $this->_auth->getIdentity()->getUser()->role;
} else {
$role = 'guest';
}

$controller = $request->controller;
$action = $request->action;
$module = $request->module;
$resource = $controller;

if (!$this->_acl->has($resource)) {
$resource = null;
}

if (!$this->_acl->isAllowed($role, $resource, $action)) {
if (!$this->_auth->hasIdentity()) {
$module = $this->_noauth['module'];
$controller = $this->_noauth['controller'];
$action = $this->_noauth['action'];
} else {
$module = $this->_noacl['module'];
$controller = $this->_noacl['controller'];
$action = $this->_noacl['action'];
}
}

$request->setModuleName($module);
$request->setControllerName($controller);
$request->setActionName($action);
}
}


Agreement.php
Many sites choose to enforce a set of terms and conditions to access. This intercepting plugin simply checks the Zend_Auth identity method hasAgreement() (for the sake of demonstration lets just say this is a boolean property that has been set in the user table of the database). Again, this is only enacted if an identity exists, and the request is redirected to a specific agreement controller/action.

<?php

class MyPlugin_Agreement extends Zend_Controller_Plugin_Abstract
{
private $_auth;

private $_noagreement = array('module' => 'default',
'controller' => 'login',
'action' => 'agreement');

public function __construct($auth)
{
$this->_auth = $auth;
}

public function preDispatch($request)
{
if ($request->controller != 'logout' && $this->_auth->hasIdentity()) {
if (!$this->_auth->getIdentity()->getUser()->hasAgreement()) {
$request->setModuleName($this->_noagreement['module']);
$request->setControllerName($this->_noagreement['controller']);
$request->setActionName($this->_noagreement['action']);
}
}
}
}


Login (Authentication)
The act of authentication - in my app - all happens within a domain model - MyForm_Login. Using Matt Zandstra's excellent reference on Observers/Observable at zend.com as a starting point I have created a form object that extends the PEAR HTML_Quickform component to allow one or more observers to be added to the form and activated upon validation.

The form is constructed (and auto-populated in my domain-specific instance with form elements like 'Username', 'Password' and a 'Remember Me' checkbox), then several observers are added to it.

When a form validates, the observers are all notified and given an instance of the form values and the Zend_Auth instance. From there, it is simply a matter of checking the sanitised form values (we've applied our form filters, right? :) and passing them to a domain-specific Zend_Auth_Identity object to query the database, perform a lookup and then either spit out an error message or start the login session.

The example below would also create a hypothetical log observer to record the login time, date, details, etc.

BTW, in case you're wondering why the $view->render() isn't called, it's because I generally have a View_Plugin that's registered in the the Front_Controller that kicks in during dispatch shutdown. It allows me to incrementally add components/properties to the view as the dispatcher loops through all the application actions.


LoginController.php
class LoginController extends Zend_Controller_Action
{
public function indexAction()
{
$auth = $this->getInvokeArg('auth');
$view = $this->getInvokeArg('view');

if ($auth->hasIdentity()) {
$this->_redirect('/home/index'); // Already authenticated? Navigate away
}

$form = new MyForm_Login(); // creates all fields, adds filters, etc...
$form->attach(new MyPlugin_Login_User($auth); // Perform login of user identity
$form->attach(new MyPlugin_Login_Log($auth); // Perhaps log the event?

if ($form->validate()) {
$this->_redirect('/home/index');
}

// Render page
$this->getInvokeArg('view')->title = 'Login';
$this->getInvokeArg('view')->template = 'login/index.tpl';
$this->getInvokeArg('view')->form = $form->render();
}

public function agreementAction()
{
$auth = $this->getInvokeArg('auth');
$view = $this->getInvokeArg('view');

$form = new MyForm_Agreement();
$form->attach(new MyPlugin_Agreement_User($auth));

if ($form->validate()) {
$this->_redirect('/home/index');
}

// Render page
$this->getInvokeArg('view')->title = 'Agreement';
$this->getInvokeArg('view')->template = 'login/agreement.tpl';
$this->getInvokeArg('view')->form = $form->render();
}
}


User.php
class MyPlugin_Login_User implements Observer
{
function notify($form)
{
$auth = $this->_auth;
$values = $form->exportValues();

$adapter = new MyAuth_Adapter();
$adapter->setUsername($values['username']);
$adapter->setPassword($values['password']);

try {
$auth->authenticate($adapter);
} catch (MyAuth_Adapter_Exception_Missing $e) {
// Let form know that login has failed...
} catch (MyAuth_Adapter_Exception_Locked $e) {
// Let form know that login has failed...
}

if (!$auth->isAuthenticated()) {
// Let form know that password was incorrect or your account is not active...
}

$identity = $auth->getIdentity();

// Retrieve row of user info and store inside Identity object (including role!)
$userTable = new MyUser_Table; // Instance of Zend_Db_Table or similar...
$identity->setUser($userTable->find($identity->getIdentifier()));
}
}


Conclusions:
-------------
This is obviously an over-simplified example that attempts to address the challenges of the Acl/Auth components in relation to the MVC components.

I believe this approach - though needing some further bulletproofing - demonstrates good practice and encourages the developer to think about logical and clean ways of separating the process of authentication. Some benefits are:-

* You could easily drop in ACL rules in the one point and have a more complex and rich set of rules without needing any update to your controllers, relieving a lot of maintenance issues.
* Processing user input happens only in a single point in an area of the application that makes it more natural for developers to understand and build upon. The filters and validation take place in a separate form model that can be replaced/updated without affecting any other portion of the process. Post-login business rules can be added without touching other plugins or the bootstrap.

I hope this is useful! Would very much appreciate feedback - even if to say I'm doing it all wrong! :-) I'm still learning a lot from listening to the discussions on this list and I'm keen to find out how others approach this kind of layer in their own applications.

Howdy folks,

Just wanted to post to let everyone know that calling parent::__construct() on a class that extends Zend_Acl will result in fatal error because Zend_Acl does not have a constructor.

So, for those of you following this old article verbatim, beware that much has changed for both Zend_Auth and Zend_Acl since this writing.

Best regards,
Darby

Hi everybody. i have implemented the acl - auth example, and it works fine. but if i use this plugin i have problem with my errorhandler (buildin errorhandler). E.g if u set a wrong url u will forwared to the loginscreen every time !!!the error handler will with his postdipatch will not be started. Is there a possibilty to use the errorhandler in combination with auth plugin ??

Best regards Thomas

Hi,

I am trying to wrap my mind around the ZF and this example helped a lot. I tried the code and works fine. Just one thing, it breaks the handling of invalid module or controller or action (HTTP 404).

I believe this is because of this plugin being a Zend_Controller_Plugin with a preDispatch hook which redirects to a login page or an error page if Acl->isAllowed() returns false (which is also true for all invalid paths).

So I used Zend_Controller_Action_Helper to implement this logic. So far my errorHandler seems to be working fine (redirecting to a 404 error page for invalid requests) and for valid requests the helper kicks in and checks the privileges.

Am I on the right track? Any comments on this?

htorun,

As I already said, this code doesn't break anything as far as the zf logic is concerned and, normally, the errorHandler works just fine with the plugin... After all that's what the aop "plugin" pattern is supposed to do, using a helper for this kinda breaks the beauty of the idea.

Once again here's how it works...

1. the $front->throwExceptions(true) statement is off => no error will be thrown by the controller;

2. prior to the dispatch of the request, the plugin's method "preDispatch($request)" will be called. At this point, nothing will happen because the controller doesn't do anything yet! It's only when the auth_rights are determined, and the request forwarded to the right action (valid or not), that the controller will dispatch the request.

3. If the dispatched request contains an invalid url, an error will be thrown (but not shown on the screen!) and caught by the errorHandler which in turn will redispatch the request to the error action.


So if if it doesn't work, you probably missed something.

htorun,

As I already said, this code doesn't break anything as far as the zf logic is concerned and, normally, the errorHandler works just fine with the plugin... After all that's what the aop "plugin" pattern is supposed to do, using a helper for this kinda breaks the beauty of the idea.

Once again here's how it works...

1. the $front->throwExceptions(true) statement is off => no error will be thrown by the controller;

2. prior to the dispatch of the request, the plugin's method "preDispatch($request)" will be called. At this point, nothing will happen because the controller doesn't do anything yet! It's only when the auth_rights are determined, and the request forwarded to the right action (valid or not), that the controller will dispatch the request.

3. If the dispatched request contains an invalid url, an error will be thrown (but not shown on the screen!) and caught by the errorHandler which in turn will redispatch the request to the error action.


So if if it doesn't work, you probably missed something.

frontpost,

Let me put it this way; as you mentioned:

2. prior to the dispatch of the request, the plugin's method "preDispatch($request)" will be called. At this point, nothing will happen because the controller doesn't do anything yet! It's only when the auth_rights are determined, and the request forwarded to the right action (valid or not), that the controller will dispatch the request.

Here is the problem. When the controller is invalid or not in the resource list (from the code):

if (!$this->_acl->has($resource)) {
$resource = null;
}

the $resource becomes null. Since Zend_Acl has a white list approach, unless you are 'admin' with unrestricted access to all resources:

if (!$this->_acl->isAllowed($role, $resource, $action))

becomes true (i.e. not authorized) redirecting to "privilege error" (or "login") page before errorHandler can do its job.

Implementing the same logic in a Zend_Controller_Action_Helper gives errorHandler the chance to do its job since it appears the action helper's preDispatch hook kicks in after the request is dispatched to a controller not before as in the case of a Zend_Controller_Plugin's preDispatch hook.

Also I don't see how action helpers break the beauty of the oop "plugin" pattern. They could very well be named as Zend_Controller_Action_Plugin since that is what they are; a plugin to an action.

frontpost,

Let me put it this way; as you mentioned:

2. prior to the dispatch of the request, the plugin's method "preDispatch($request)" will be called. At this point, nothing will happen because the controller doesn't do anything yet! It's only when the auth_rights are determined, and the request forwarded to the right action (valid or not), that the controller will dispatch the request.

Here is the problem. When the controller is invalid or not in the resource list the resource becomes null.

Since Zend_Acl has a white list approach, unless you are 'admin' with unrestricted access to all resources, you get "not allowed" redirecting to "privilege error" (or "login") page before errorHandler can do its job.

Implementing the same logic in a Zend_Controller_Action_Helper gives errorHandler the chance to do its job since it appears the action helper's preDispatch hook kicks in after the request is dispatched to a controller not before as in the case of a Zend_Controller_Plugin's preDispatch hook.

Also I don't see how action helpers break the beauty of the oop "plugin" pattern. They could very well be named as Zend_Controller_Action_Plugin since that is what they are; a plugin to an action.

thanks for this tutorial. I'm a ZF beginner (yes I know that I should start with something easier than the ACL package ^^) and I don't know where I should put these files. Can I have the sources please ?
(andrasz[@]gmail.com) Thanks.

article is very helpful.
thanks.

but
!$this->_acl->isAllowed($role, $resource, $action)
always going to 'true' when we have invalid url.

So
else {
$module = $this->_noacl['module'];
$controller = $this->_noacl['controller'];
$action = $this->_noacl['action'];
}
changes the request to $this->_noacl['module']... before dispatching.

i did
if (!$this->_acl->isAllowed($role, $resource, $action)
&& Zend_Controller_Front::getDispatcher()->isDispatchable($request))

Hi,

I would like to have an editbutton/link in my view. The view is a list of products. Only the 'editor' role may edit. The rest ('guest') my not see the editbutton at all. So, I want an $acl->isAllowed() somewhere in my MVC. But where?? Or is there another/better way?

kind regards,
Richard

There is a error in this example. In the comments (the complete code) you state: $action = $request->action... This is fine with a normal request. But as soon as you use a _forward your request will break and you end up in a endless-loop.

Better and safe is this method: $this->getRequest()->getActionName(), then you will get the correct action name, even when coming from an forward!