We will first look at a simple example with users and pages, and then we’ll have a more complex example, involving building a much more complex ACL with inheritance, role types and other stuff.

The idea behind dynamic ACLs

As we have previously looked at ACLs which are hardcoded, we will now look at building a “dynamic” ACL. Previously shown “static” ACLs are good for quick and simple sites, but when you actually require the ability for administrators to define access rights on the fly using an admin panel, they quickly lose their usefulness.

Also, when working with very large amounts of users or roles, it may not be a very good idea to always construct the full ACL. This is one of the things we’ll discuss in this part: Creating ACLs with only the parts that are required to perform a specific access check.

Let’s say you have a user, and you have to check if the user has access to a specific page. Would it make sense to load the complete ACL, with all your users, all your pages and then set up all their access rights? Nope, not really. It’s a better idea to simply create an ACL with just the single user, and the single resource we need to check against.

A simple example with users and pages

Let’s first start with a relatively simple case: We have a site with some pages, and we need to be able to define which users can access which pages. By default, nobody can access a page, unless we specifically allow it. Later in this post, we’ll look at a more complex set up.

To the right you can see a database table schema for this example. As you can see, it’s relatively simple with just three tables.

1. Pages table holds our site’s pages
2. Users table holds our site’s users
3. Page_privileges table holds data on which user has been granted access to which page

In this case, it makes sense to store ACL roles and resources as numbers: Each user is a role, and each page is a resource, thus we can easily store them in the ACL as their respective ID’s from the database.

An ACL factory

Before going any further, let’s introduce a concept we’ll be using throughout this post – an ACL factory class. The factory will be used to construct our ACL instances. This will allow us to keep better track of the code that is creating the ACL, and keep everything related to its initialization in a single place. By doing this, we can also specify things like table names or such in later on the post.

This is the basic factory we’ll be using now:

class AclFactory {
  /**
   * Creates an ACL for a specific page
   * @param Page $page
   * @return Zend_Acl
   */
  public function createAcl(Page $page) {
    //Lets assume we have a model for the page_privileges with a method like this
    //which would return PagePrivilege objects with the page_id passed as the param.
    $privileges = PagePrivilege::findByPageId($page->getId());
 
    $acl = new Zend_Acl();
    $acl->add(new Zend_Acl_Resource($page->getId()));
 
    foreach($privileges as $privilege) {
      $acl->addRole(new Zend_Acl_Role($privilege->getUserId()));
      $acl->allow($privilege->getUserId(), $page->getId());
    }
 
    return $acl;
  }
}

The way the method works is it first gets all privileges for the page – every row with the page’s ID as the page_id. We then create a new Zend_Acl instance, and add a resource with the page’s ID. Then it’s simply a loop, which adds each user_id found from the table to the ACL as a role, and marks the page as allowed for the user.

But how does this work? Because we are using the user IDs as the role IDs, we can loop over each found privilege, and add the user id in it to the ACL. This way, the ACL will have all possible roles for this resource in it. Similarily, since the privilege means the user has access to the page, we also allow the user to access the page.

Using the ACL factory

Now that we have the code which can build an ACL for us, let’s see how it could be used:

//Lets say $page is a page we want to access
$factory = new AclFactory();
$acl = $factory->createAcl($page);
 
//and $user is the currently logged in user
if($acl->hasRole($user->getId()) && $acl->isAllowed($user->getId(), $page->getId()) {
  //Access OK
}

So we use the factory to build an ACL, and then we use it as normal. This time we also use the hasRole method to test if the ACL actually even has the user’s role – since we are only adding the roles that actually have access to the page, the user may not be in the ACL, and if the role does not exist when you call isAllowed, you will get an exception.

Complex example: A file directory

Now that we’ve covered the basics, let’s dive in a bit deeper: How to implement an ACL system for a system which can be used to serve files to users.

Click for bigger image

The file system’s access will be defined like this:

• It can have multiple categories, which can contain one or more files
• Access to categories or files will be inherited from the parent(s)
• Users can belong to one or more groups
• A user or a group can have access defined to specific files or categories

So in terms of Zend_Acl, we can talk of categories and files as resources. Files will inherit permissions from the category they belong to, and categories will inherit from any parent categories they may have.

Since we won’t go into much details about the database and all that, you can take a look at the database diagram presented on the right. Full source code for a ZF file system application based on this is also available towards the end of this post, which contains SQL for creating the tables, and all the code required.

Initial set up

We’ll assume few things on the system: we will have a predefined group in the database: guests

A user who isn’t logged in will be assigned an identity which belongs only to the group guests. Thus we can limit access to guests using the ACL if we want.

We’ll also have a model class representing each of the tables with getters and setters, in a similar fashion as the NewsPost example model shown in the practical uses for reflection post. In addition, we will have some classes which can be used to fetch instances of the models from the database, or store them.

Starting out

Most of the big things will be going on in the ACL factory class. We will modify the one introduced earlier to suit this more complex example. It will have two public methods: createFileAcl and createCategoryAcl. We’ll take a look at the latter first:

public function createCategoryAcl(Category $category, User $user) {
  $acl = new Zend_Acl();
  $this->_createRoles($acl, $user);
 
  $categories = $category->getParents() + array($category);
 
  //Top category has no parent, so it's null at first
  $parent = null;
  foreach($categories as $c) {
    $acl->add($c, $parent);
    //next will have this as the parent
    $parent = $c;
  }
 
  $privileges = Privilege::findByCategories($categories);
  $this->_setPrivileges($acl, $privileges);
  return $acl;
}

So basically the method takes a Category object and a User object as its parameters. We will look at the _createRoles and _setPrivileges methods soon.

The Category class implements the Zend_Acl_Resource_Interface as shown previously, so the code in the factory can simply pass the objects to add() when creating the ACL.

This also shows how resource inheritance can be done: We simply take all the parents of the category and make them inherit from each other by passing them as arguments to add.

The getParents method will return all parents of a Category, as the farthest parent at 0, and closer at 1, 2 and so on. As the top level category will not have a parent, we first make it null. As we process the array, we change the parent category to the processed one, so the next category gets it as its parent.

The Privilege class’ method findByCategories will return all privilege objects for certain categories. Refer to the database diagram to see what it represents.

Private methods

In the category acl method, the code calls _createRoles. The job of this function is to create the role entries for the user object in question.

private function _createRoles(Zend_Acl $acl, User $user) {
  //add groups first so user can inherit them
  foreach($user->getGroups() as $group) {
    $acl->addRole($group);
  }
 
  $acl->addRole($user, $user->getGroups());
}

So by calling this method, the ACL gets filled with all the user’s roles. Similar to the Category class, the User and Group classes implements Zend_Acl_Role_Interface, so we can again just pass them to addRole without having to worry about it. You can later take a look at the code at the end of the post for a better idea of these classes.

The _setPrivileges method has a bit more code: its job is to look at the Privilege objects, and see if it needs to allow or deny access based on them

private function _setPrivileges($acl, $privileges) {
  foreach($privileges as $privilege) {
    $role = $privilege->getRole();
    $resource = $privilege->getResource();
    //the user's roles should already exist so we can
    //ignore the ones that don't
    if(!$acl->hasRole($role)) {
      continue;
    }
 
    if($privilege->getMode() == 'allow')
      $acl->allow($role, $resource);
    else
      $acl->deny($role, $resource);
  }
}

The Privilege class has methods for getting the relevant role and resource classes. Depending on the type, the role returned could be a User object or a Group object, and the resource could be a Category object or a File object. Since they all implement the interfaces for their types, they can be passed to Zend_Acl right away without having to do any additional logic.

ACLs for files

Now for the other public method in the class.

public function createFileAcl(File $file, User $user) {
  $acl = null;
  if($file->getCategoryId() != null) {
    //if the file belongs to a category
    //we need to build the whole category based acl
    $category = $file->getCategory();
    $acl = $this->createCategoryAcl($category, $user);
    $acl->add($file, $category);
  }
  else {
    $acl = new Zend_Acl();
    $this->_createRoles($acl, $user);
    $acl->add($file);
  }
 
  $privileges = Privilege::findByFile($file);
  $this->_setPrivileges($acl, $privileges);
  return $acl;
}

Since a File can belong to a category, we need to build the category ACL first. This can be easily done by calling the other method. In the case the File doesn’t belong to any category, it’s assumed to be on the top level, and it won’t inherit from anything. The file itself may also have some privileges of its own, so we fetch them and call the _setPrivileges method to process them.

Final bunch of code

We have one more ACL related class to look at: The plugin, or how to use the ACL factory in this case. This one is a bit longer, but it should be easy to understand as it’s pretty typical stuff:

<?php
class App_Plugin_AccessCheck extends Zend_Controller_Plugin_Abstract {
  public function preDispatch(Zend_Controller_Request_Abstract $request) {
    if(!$this->_accessValid($request)) {
      //we throw an exception because the error controller
      //can easily handle these
      throw new App_Exception_AccessDenied('Access denied');
    }
  }
 
  private function _accessValid(Zend_Controller_Request_Abstract $request) {
    $user = $request->getParam('user', null);
 
    //the identityloader plugin should have added a user to
    //the request and if it doesn't exist something is wrong
    if($user === null)
      return false;
 
    $params = $request->getParams();
    $factory = new App_AclFactory();
    $resource = null;
 
    if(isset($params['file'])) {
      $resource = File::findById($params['file']);
      $acl = $factory->createFileAcl($resource, $user);
    }
    elseif(isset($params['category'])) {
      $resource = Category::findById($params['category']);
      $acl = $factory->createCategoryAcl($resource, $user);
    }
    else {
      //since we only care about access to files/categories,
      //we'll return true if those aren't being accessed
      return true;
    }
 
    return $acl->hasRole($user) && $acl->has($resource)
      && $acl->isAllowed($user, $resource);
  }
}

This is a plugin which will use the ACL to test access. As we mentioned earlier, by default users who haven’t logged in will automatically belong to a guests-group, so we have some other code that loads a user object to the request. We take this parameter in the accessValid method and test it against the ACL.

It also looks at some other parameters of the request to determine if the user is trying to access a file or a category, and acts accordingly.

Summing up

So this time we had a bit more complex usage of Zend_Acl. I didn’t write all about the models used, the SQL and all that to keep it at least on a some kind of manageable level for you, but fear not – all the code that I did not show is downloadable!

Click here to download the filesystem project

I have commented certain parts of the code, but I must warn you that the code is probably quite far from optimal. It does not always use safe SQL, it does lots of extra queries in certain cases, it probably does not take care of possible erroneus conditions very well… but it does what it’s supposed to: it demonstrates how you can implement a more complex database-backed dynamic ACL system!… Oh, and it doesn’t have an admin page, so you’ll have to insert all the test data to the DB yourself

I don’t have any more chapters to this series planned out, but if you have any questions, or if some part of this wasn’t particularily clear, feel free to have your say in the comments! I might write a followup post to answer your questions if there are some more complex ones on anyones mind.

You may have noticed I didn’t cover Zend_Acl_Assertions. That’s because I couldn’t think of any use for them. =)

If you liked this series, remember to subscribe to the RSS feed to get new posts automatically to your feed reader.

Further reading:
In addition to this series on Zend_Acl, I’ve written the following posts which look a bit more on the theory side of access control and authentication:
Implementing swappable authentication methods, which explains how you could make your authentication method easily changeable between, for example, LDAP and a database.
Extensible authentication and access-control, which talks more about creating a generic auth/acl system which can be easily extended so it works with different systems like database or LDAP

Now, the post: This time, we’ll look at Zend_Acl a bit deeper after the first part

Applications often have different resources: For example, you might have pages, some user generated content like comments, and an admin area. You might also have files, or even real-life objects like a coffee machine.

In the context of Zend_Acl, access to resources is given to roles: A role might be a user’s name, a group a user belongs to, or just roles, which have been assigned to a user from the admin panel.

Since Zend_Acl only defines an “abstract” role, resource and privilege, how do we deal with all of these using it? Read more to find out! I’ll also be addressing some more ways to deal with allowing and denying access.

Dealing with individual users and usergroups

Let’s say we want to be able to limit access to specific resources based on a user, or a usergroup. How do we accomplish this?

Since each role in Zend_Acl is identified by a string, we can come up with our own role-scheme: For users, the role id will be user-username, and for usergroups, the role id will be group-groupname.

$acl->addRole(new Zend_Acl_Role('user-john'));
$acl->addRole(new Zend_Acl_Role('group-accounting'));

To check against the ACL in this kind of a scenario, we could have something like this:

//We'll assume $user is some kind of a User object
$name = $user->getName();
$groups = $user->getGroups();
 
$roles = array('user-' . $name);
foreach($groups as $g) 
  $roles[] = 'group-' . $g->getName();
 
foreach($roles as $r) {
  if($acl->isAllowed($r, 'someresource', 'someprivilege') {
    //allowed, do something.
  }
}

Improving the user/group example by using Zend_Acl_Role_Interface

In our above example with the strings, there’s a small problem: The strings.

We use user-something and group-something. What if we need to use it in some other place too? We may easily end up with code duplication, and it can become difficult to keep track of changes. In the case we add even more possible role types, it may become an even bigger mess if we introduce some more code which converts the new role type into a string!

Luckily, there’s a quite simple way out of this: by using Zend_Acl_Role_Interface with our objects.

As the user and groups in the example are classes, we could have them implement the role interface. That way we can simply pass the objects to the ACL instead of having to turn them into strings.

class User implements Zend_Acl_Role_Interface {
  //contents of the class here
 
  //this method is for the role interface:
  public function getRoleId() {
    return 'user-' . $this->_name;
  }
}

So we add a method called getRoleId to the class, which returns an identifier for the object. We’ll also add that to our Group class, but with the difference that it returns an id with group- prefix. The earlier code which checks the ACL now looks like this:

//We simply put the user and the groups in an array and be done with it
$roles = array($user) + $user->getGroups();
foreach($roles as $r) {
  if($acl->isAllowed($r, 'someresource', 'someprivilege') {
    //allowed, do something.
  }
}

Different resource types

Just like roles, resources are strings. Resources can also be represented by objects which implement an interface – Zend_Acl_Resource_Interface. You can apply the code shown for roles in this.

Let’s take a quick example with files. Remember our plugin from the first in the series? Here’s it again:

class My_Plugin_Acl extends Zend_Controller_Plugin_Abstract {
  private $_acl = null;
 
  public function __construct(Zend_Acl $acl) {
    $this->_acl = $acl;
  }
 
  public function preDispatch(Zend_Controller_Request_Abstract $request) {
    //As in the earlier example, authed users will have the role user
    $role = (Zend_Auth::getInstance()->hasIdentity())
          ? 'user'
          : 'guest';
 
    //For this example, we will use the controller as the resource:
    $resource = $request->getControllerName();
 
    if(!$this->_acl->isAllowed($role, $resource, 'view')) {
      //If the user has no access we send him elsewhere by changing the request
      $request->setModuleName('auth')
              ->setControllerName('auth')
              ->setActionName('login');
    }
  }
}

Let’s modify this so we can also use files with our ACL.

Creating our resources

We will first create a resource type for controllers, as it isn’t very simple to just create them on the fly for the sake of ACL testing, and then we will look at the File resource.

class Resource_Controller implements Zend_Acl_Resource_Interface {
  public function __construct($id) {
    $this->_id = $id;
  }
 
  public function getResourceId() {
    return 'controller-' . $this->_id; 
  }
}

We create this resource class for the controllers because it would be a bit tricky to create the controller in the ACL just so we could check against it. This class will make the job easier on us.

Now, you probably should have a model class which represents a file, so you’ll just need to make the class implement the Zend_Acl_Resource_Interface

class File implements Zend_Acl_Resource_Interface {
  /* we can have some methods related to the file model here */
 
  public function getResourceId() {
    return 'file-' . $this->_name; 
  }
}

So this assumes that your File model has a property $_name. The name is then used with the resource id.

Modifying the plugin

Now, we need to first modify the ACL plugin to use the controller resource. We’ll also modify it to use the earlier introduced User class as the role:

public function preDispatch(Zend_Controller_Request_Abstract $request) {
  //Let's assume that the identity is a User object this time
  $user = Zend_Auth::getInstance()->getIdentity();
 
  //We need to create a new controller resource using the name:
  $resource = new Resource_Controller($request->getControllerName());
 
  if(!$this->_acl->isAllowed($user, $resource, 'view')) {
    //If the user has no access we send him elsewhere by changing the request
    $request->setModuleName('auth')
            ->setControllerName('auth')
            ->setActionName('login');
  }
}

Okay, so as the user object already implements the role interface, we can pass it to isAllowed. Same with the resource.

Important: Remember that you need to use the Resource_Controller and User classes when creating the ACL! Otherwise this will not work!

//assume $someUser is an user object
$this->addRole($someUser);
 
//assume $someController is a Resource_Controller object
$this->add($someController);
 
$this->allow($someUser, $someController, 'view');

You may notice that this approach doesn’t work very well with static ACLs which are written in code. Next week, we will look at how to create dynamic ACLs, where this kind of approach works better! But for now, let’s continue.

Creating a new plugin

We could add the code for checking access to files to our earlier plugin, but if we create a separate plugin for it, it will be easier to reuse with other code. Let’s assume that we have some code which serves files to our users. When a user wants to download a file, the request will have the parameter file, which will contain the file’s name.

This will be a very similar plugin to the first:

class My_Plugin_Acl_File extends Zend_Controller_Plugin_Abstract {
  private $_acl = null;
 
  public function __construct(Zend_Acl $acl) {
    $this->_acl = $acl;
  }
 
  public function preDispatch(Zend_Controller_Request_Abstract $request) {
    //This too will use the user object from zend_auth
    $user = Zend_Auth::getInstance()->getIdentity();    
 
    //Instead of using the controllers name, we'll use the parameter
    $filename = $request->getParam('file');
 
    //If the request is not for a file we can just exit here without doing anything
    if(empty($filename))
      return;
 
    $resource = new File();
    $resource->setName($filename);
 
    if(!$this->_acl->isAllowed($role, $resource, 'view')) {
      $request->setModuleName('auth')
              ->setControllerName('auth')
              ->setActionName('login');
    }
  }
}

So this is basically the same as the earlier, but instead of checking for the controller, we check for a file.

Note: instead of creating a new File(), it may be a good idea to use some class to fetch a file model, and to check if there even is a file with the required name.

More on allowing and denying access

As we have seen a few times, we can allow access to ACL resources with the allow method. However, there are some additional things I haven’t mentioned yet.

If you allow access to resource null, but with some privilege, it effectively means the role will have that privilege for all resources, unless explicitly denied:

//myrole will get dosomething privilege on *all* resources
$acl->allow('myrole', null, 'dosomething');

Similarily, allowing on null privilege will give every privilege on a resource:

//myrole will get all privileges on someresource (privilege defaults to null)
$acl->allow('myrole', 'someresource');

The isAllowed method has similar features. If you don’t define the privilege while checking for access to a resource, it will require that the role has all privileges on the resource.

You can also give access to all resources and all privileges by leaving out both the resource and privilege when calling allow. Or, you can omit the role too, which will allow everyone access to everything – essentially requiring you to explicitly deny access if you don’t want certain roles accessing certain resources. This can be useful for creating blacklist-style behavior.

In closing

Even though we have gone through lots of ways to use Zend_Acl, there’s still a much to cover. Next week we will look at how to build “dynamic” ACLs from database or files, and we will again improve our ACL code and plugins.

You can read the third post of the series here

Notes: it may be a good idea to modify the plugins introduced in this post to actually check if there is an identity before proceeding. If there is no identity, it’s very likely that isAllow will throw an exception, or behave in an unexpected way. You also should check if the resource/role exist in the ACL, or you will likely get an exception.

Much of the examples in this post will work better when the ACL is created dynamically from a database. This is because models and such require database access to begin with, and creating them on the fly as seen in the examples may not be a good idea. However, it’s important to understand these things before moving on.

These things will be addressed in future posts in the series.

Later in the post series I’ll be talking about some more advanced ways of utilizing Zend_Acl, and topics such as database-backed ACLs.

A russian translation of this post is available here, courtesy of Rashad Surkin.

Zend_Acl misconceptions

Many people think that the ACL “resource” and “privilege” are the same as the controller and the action. This is not true!

The resource in Zend_Acl can be anything – a controller, a file, a model…

The privilege, just like the resource, can be anything related to the resource – for example, it could be an action if the resource is a controller, or it could be “read” or “write” if it’s a file or a model.

Later in the series, I’ll show some other ways of using acl resources, privileges and roles.

Building a simple ACL

As mentioned earlier, Zend_Acl constists of resources, privileges, and additionally, roles. Resources can be anything ranging from controllers to files. Privileges are different levels of access on the resource. Roles determine who can access a resource, and with what privileges. Roles can be users, user groups or anything you wish to associate such data with.

The very simplest way you can use Zend_Acl is building the ACL in code. This is often a useful approach for simple cases, where you only have a handful of resources and roles.

class My_Acl extends Zend_Acl {
  public function __construct() {
    //Add a new role called "guest"
    $this->addRole(new Zend_Acl_Role('guest'));
 
    //Add a role called user, which inherits from guest
    $this->addRole(new Zend_Acl_Role('user'), 'guest');
 
    //Add a resource called page
    $this->add(new Zend_Acl_Resource('page'));
 
    //Add a resource called news, which inherits page
    $this->add(new Zend_Acl_Resource('news'), 'page');
 
    //Finally, we want to allow guests to view pages
    $this->allow('guest', 'page', 'view');
 
    //and users can comment news
    $this->allow('user', 'news', 'comment');
  }
}

Now, by creating a new instance of My_Acl, we could perform simple checks against the acl. But what is allowed, and for who?

The guest role gets a privilege called view on the resource page. Since the user role inherits from guest, it also gets this privilege. The news resource inherits from page, so everyone who has privileges on the page resource, has the same privileges on news. In the last line of the constructor, we add a privilege comment for the user role on news. Only the user role has the privilege comment in the news resource – guest does not.

Note: The names used in the example for the roles and resources are just identifiers. They could be 1, 2, or whatever, but it’s often easier to understand identifiers that are human-readable. However, when generating ACLs from databases or other source, it may not be necessary to have human-readable identifiers – the primary key from a database row will do just fine. Again, later in the series I’ll show an example of this.

Using the simple ACL

Using an ACL class is quite simple. You just call the method isAllowed with a role, resource and a privilege. The main difficulty is in determining what is the role, resource and the privilege.

How do we determine, what is the role? This can be a very simple if-clause: if there is a logged-in user, then the role is user, otherwise it is guest.

What about the resource? Depending on the application, this could be guessed from the file name included. For example, with our simple ACL, we could have a file called page.php and a file called news.php. page would check against the page resource, and news would check against the news resource.

And lastly, the privilege? When simply loading the page, you could use the view privilege. The code could later on check for other privileges: for example, the code could check if you have access to the comment privilege and display a comment box.

Here’s a really simple example:

$role = 'guest';
if(isset($_SESSION['auth']))
  $role = 'user';
 
$acl = new My_Acl();
 
if($acl->isAllowed($role, 'news', 'comment')) {
  //Some code here to display a news box
}

As you can see, it’s quite easy to use the ACL even without Zend Framework, and you can easily speed up development of non-ZF apps by using the ACL component as it will save time when you won’t need to implement complex authorization checking code.

The above example may be very simple, but it shows you the basic way ACLs are used.

Using the simple ACL in Zend Framework applications

In Zend Framework applications, the resource and privilege can often be determined from the request object.

Typically, we would create a plugin which checks the acl for us:

class My_Plugin_Acl extends Zend_Controller_Plugin_Abstract {
  private $_acl = null;
 
  public function __construct(Zend_Acl $acl) {
    $this->_acl = $acl;
  }
 
  public function preDispatch(Zend_Controller_Request_Abstract $request) {
    //As in the earlier example, authed users will have the role user
    $role = (Zend_Auth::getInstance()->hasIdentity())
          ? 'user'
          : 'guest';
 
    //For this example, we will use the controller as the resource:
    $resource = $request->getControllerName();
 
    if(!$this->_acl->isAllowed($role, $resource, 'view')) {
      //If the user has no access we send him elsewhere by changing the request
      $request->setModuleName('auth')
              ->setControllerName('auth')
              ->setActionName('login');
    }
  }
}

We could have made the ACL static – instead of passing it in the constructor, we could have just created it in the preDispatch method. However, by passing it as a parameter, we make it easier to reuse this plugin. If we create a different ACL class, this plugin will still work with it without modifications.

Now that we have a plugin, we need to add it to the front controller in the boostrap:

$acl = new My_Acl();
 
//assuming $fc is the front controller
$fc->registerPlugin(new My_Plugin_Acl($acl));

Now every request will be checked against the acl, and anyone without the view privilege would not get through.

Note: if you use the My_Acl class as-is, you may get an infinite loop! The code in the plugin is sending the user to Auth module’s AuthController’s loginAction. It also uses the controller’s name as the resource ID… but My_Acl does not have a resource called auth! So if you want to make it work, you need to add a resource called auth to the ACL, and have it inherit from page, as we already gave guest the necessary privileges to page.

But how do we check for the comment privilege?

You could add some code to the controller, which checks for the required privilege, and then sets a variable in the view to true:

public function someAction() {
  $role = (Zend_Auth::getInstance()->hasIdentity())
        ? 'user'
        : 'guest';
 
  //assuming $this->_acl contains the acl
  $this->view->canComment = $this->_acl->isAllowed($role, 'news', 'comment');
}

It may be a good idea to modify the code so that you won’t need to duplicate the role check. For example, you could store the role in the auth identity, or you could create an action helper which is used to access the acl and contains all relevant data.

In closing

Armed with this knowledge, you should be able to get started with Zend_Acl!

Next week’s post is going to deal with some more advanced Zend_Acl usage scenarios:

• Dealing with different resource types, such as controllers and files
• Dealing with different role types, such as users and user groups

You can read the next post in the series here