1.2. Refining Access Controls

1.2.1. Precise Access Controls

The basic ACL as defined in the previous section shows how permissions can be applied at a general level. In practice, however, access controls tend to have exceptions and varying degrees of complexity. Zend_Acl allows to you accomplish these refinements in a straightforward and flexible manner.

For the example CMS, it has been determined that whilst the 'staff' group covers the needs of the vast majority of users, there is a need for a new group that requires access to the newsletter and latest news in the CMS. The group is fairly self-sufficient and will have the ability to publish and archive both newsletters and the latest news.

In addition, it has also been requested that the 'staff' group be allowed to view news stories but not to revise the latest news. Finally, it should be impossible for anyone (administrators included) to archive any 'announcement' news stories since they only have a lifespan of 1-2 days.

First we revise the ARO registry to reflect these changes. We have determined that the 'marketing' group has the same basic permissions as 'staff', so we define 'marketing' in such a way that it inherits permissions from 'staff':

// The new marketing group inherits permissions from staff
$aro->add('marketing', $aro->staff);

Then it is simply a matter of adding permissions to this new group on the target areas within the ACL:

// Marketing must be able to publish and archive newsletters
$acl->newsletter->allow($aro->marketing, array('publish', 'archive'));

// It also needs to be able to publish and archive the latest news
$acl->news->latest->allow($aro->marketing, array('publish', 'archive'));

// Staff and marketing (by inheritance), are denied permission to revise the latest news
$acl->news->latest->deny($aro->staff, 'revise');

// Everyone (including administrators) are denied permission to archive news announcements
$acl->news->announcement->deny(null, 'archive');

We can now query the ACL with respect to the latest changes:

echo $acl->newsletter->pending->valid($aro->staff, 'publish') ?
     "allowed" : "denied"; // denied

echo $acl->newsletter->pending->valid($aro->marketing, 'publish') ?
     "allowed" : "denied"; // allowed

echo $aro->staff->canAccess($acl->news->latest, 'publish') ?
     "allowed" : "denied"; // denied

echo $aro->marketing->canAccess($acl->news->latest, 'publish') ?
     "allowed" : "denied"; // allowed

echo $aro->editor->canAccess($acl->news->announcement, 'archive') ?
     "allowed" : "denied"; // denied

1.2.2. Removing Access Controls

To remove one or more access rules from the ACL, simply use the available removeAllow() or removeDeny() methods. As with allow() and deny(), you may provide a null value to indicate application to all AROs, and the context may also be null, indicating all contexts, or a string or an array of strings, where the strings indicate the specific contexts to which the removal applies:

// Remove the denial of revising latest news to staff (and marketing, by inheritance)
$acl->news->latest->removeDeny($aro->staff, 'revise');

// Remove the allowance of publishing and archiving newsletters to marketing
$acl->newsletter->removeAllow($aro->marketing, array('publish', 'archive'));

Permissions may be modified incrementally as indicated above, but null values will override such incremental changes:

// Allow marketing all permissions upon the latest news
$acl->news->latest->allow($aro->marketing, null);