PHP5

В Zend_Acl создать ресурс очень просто. Zend_Acl предоставляет Zend_Acl_Resource_Interface, чтобы облегчить разработчикам процесс создания ресурса. Класс должен только реализовать этот интерфейс, который состоит из одного метода, getResourceId(), для того, чтобы Zend_Acl рассматривал объект как ресурс. Дополнительно, Zend_Acl также содержит Zend_Acl_Resource, как базовый класс, который разработчики могут расширять по желанию.

Zend_Acl предусматривает структуру в виде дерева, в которое могут добавляться многочисленные ресурсы (или "подконтрольные зоны"). Так как ресурсы добавлены в такую структуру, они могут быть организованы от общих (корень дерева) к специфическим (листья дерева). При запросах к определенным ресурсам в иерархии будет выполнен автоматический поиск правил, относящихся к ресурсам-предкам, учитывающий простое наследование правил. Например, если некое общее правило должно действовать в каждом здании города, то проще прикрепить его к городу, нежели крепить к каждому зданию в городе. Однако, для некоторых зданий потребуются исключения из этого правила, в Zend_Acl это достигается путем закрепления исключений из правила за каждым зданием, которое нуждается в этом. Ресурс может наследоваться только от одного родительского ресурса, однако сам родительский ресурс может, в свою очередь, наследоваться от своего родительского ресурса и т.д.

Zend_Acl также поддерживает права доступа к ресурсам (например, "создание", "чтение", "обновление", "удаление"), и разработчик может закреплять правила, которые будут влиять на все или определенные права доступа к ресурсу.

Как и в случае с ресурсами, создавать роль также очень просто. Zend_Acl предоставляет Zend_Acl_Role_Interface, чтобы облегчить разработчикам процесс создания ролей. Класс должен только реализовать этот интерфейс, который состоит из одного метода, getRoleId(), для того, чтобы Zend_Acl рассматривал объект как роль. Дополнительно, Zend_Acl также содержит Zend_Acl_Role, как базовый класс, который разработчики могут расширять по желанию.

В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями. Например, пользовательская роль, такая как "Салли", может принадлежать одной или нескольким родительским ролям, таким как "редактор" и "администратор". Разработчик может привязывать правила к "редактору" и администратору раздельно, и "Салли" будет наследовать правила обоих ролей. Нет необходимости привязывать правила непосредственно к "Салли".

Хотя множественное наследование ролей - очень полезная возможность, она также усложняет разработку. Следующий пример демонстрирует неопределенное условие и показывает как Zend_Acl решает эту проблему.

<?php
require_once 'Zend/Acl.php';
$acl = new Zend_Acl();

require_once 'Zend/Acl/Role.php';
$acl->addRole(new Zend_Acl_Role('guest'))
    ->addRole(new Zend_Acl_Role('member'))
    ->addRole(new Zend_Acl_Role('admin'));

$parents = array('guest', 'member', 'admin');
$acl->addRole(new Zend_Acl_Role('someUser'), $parents);

require_once 'Zend/Acl/Resource.php';
$acl->add(new Zend_Acl_Resource('someResource'));

$acl->deny('guest', 'someResource');
$acl->allow('member', 'someResource');

echo $acl->isAllowed('someUser', 'someResource') ? 'allowed' : 'denied';
            

	Замечание
	Когда определяется нескольких родительских ролей, то не забывайте, что последний указанный родитель будет первым в списке поиска правил для запроса авторизации.

ACL может представлять любое множество физических или виртуальных объектов. В целях демонстрации, мы создадим базовый функционал ACL для системы управления контентом (CMS), который будет поддерживать нескольких уровней групп к множеству областей. Чтобы создать новый объект ACL, производим инстанцирование без параметров:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();
        

	Замечание
	До тех пор, пока разработчик не определит какое-либо правило, разрешающее доступ, Zend_Acl отказывает всем ролям в доступе ко всем привилегиям на все ресурсы.

Системы управления контентом почти всегда нуждаются в иерархии доступа для определения авторских возможностей своих пользователей. Это может быть группа "Гость", предоставляющая ограниченный доступ для демонстрации, группа "Сотрудник" - группа большинства пользователей CMS, которые производят каждодневные операции, группа "Редактор" - для тех кто публикует и редактирует, архивирует и удаляет контент, и, наконец, группа "Администратор", участники которой могут выполнять все операции, которые доступны участникам других групп, а также управлять закрытой информацией, пользователями, конфигурировать адинистративной части, а также делать резервное копирование/восстановление данных. Этот набор прав доступа может быть представлен в реестре ролей, позволяя каждой группе наследовать привилегии родительской группы, при этом имея индивидуальные права доступа. Права доступа могут быть изображены в следующем виде:

Для этого примера мы используем Zend_Acl_Role, но можно было бы использовать любой класс, который реализует интерфейс Zend_Acl_Role_Interface. Эти группы могут быть добавлены в реестр ролей следующим образом:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

//Добавить группы в реестр Ролей используя Zend_Acl_Role
require_once 'Zend/Acl/Role.php';

// Гость не наследует управление доступом
$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);

//Сотрудник наследуется от Гостя
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);

/*
Альтернатива тому, что написано выше:
$acl->addRole(new Zend_Acl_Role('staff'), 'guest');
//*/

//Редактор наледуется от Посетителя
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');

//Администатор не наследует управление доступом
$acl->addRole(new Zend_Acl_Role('administrator'));
        

Теперь, когда ACL содержит все необходимые роли, можно определить правила, по которым роли будут иметь доступ к ресурсам. Вы, должно быть, заметили, что мы не определили ни одного отдельного ресурса для этого примера, это упрощает демонстрацию того, что правила применяются ко всем ресурсам. Zend_Acl предоставляет реализацию, посредством которой правила должны передаваться от общих к специфическим, минимизируя таким образом количество необходимых правил, так как ресурсы и роли наследуют правила, которые определены для их предков.

В результате мы можем определить умеренно сложный набор правил минимальным кодом. Чтобы определить базовые права доступа, описанные выше:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

require_once 'Zend/Acl/Role.php';

$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');
$acl->addRole(new Zend_Acl_Role('administrator'));

// Гость может только просматривать контент
$acl->allow($roleGuest, null, 'view');

/* другим способом, предыдущий блок кода может быть записан в таком виде:
$acl->allow('guest', null, 'view');
//*/

// Сотрудник наследует привилегии просмотра у Гостя, но также нуждается в дополнительных привилегиях
$acl->allow('staff', null, array('edit', 'submit', 'revise'));

// Редактор наследует привилегии просмотра, редактирования, отправки и исправлений у Посетителя
// но также нуждается в дополнительных привилегиях
$acl->allow('editor', null, array('publish', 'archive', 'delete'));

// Администратор не наследует ничего, но обладает всеми привилегиями
$acl->allow('administrator');
        

Значение null в вызовах allow() в этом примере используется для указания того, что правила, предоставляющие доступ, применяются ко всем ресурсам.

Теперь у нас есть гибкий ACL, который может использоваться для определения того, достаточно ли прав имеет запрашивающий, чтобы производить действия в веб-приложении. Используя метод isAllowed(), производить запросы достаточно просто:

<?php
echo $acl->isAllowed('guest', null, 'view') ?
     "allowed" : "denied"; // allowed

echo $acl->isAllowed('staff', null, 'publish') ?
     "allowed" : "denied"; // denied

echo $acl->isAllowed('staff', null, 'revise') ?
     "allowed" : "denied"; // allowed

echo $acl->isAllowed('editor', null, 'view') ?
     "allowed" : "denied"; // allowed из-за наследования от Гостя

echo $acl->isAllowed('editor', null, 'update') ?
     "allowed" : "denied"; // denied, так как нет разрешающего правила для 'обновления'

echo $acl->isAllowed('administrator', null, 'view') ?
     "allowed" : "denied"; // allowed, т.к. администратор обладает всеми привилегиями

echo $acl->isAllowed('administrator') ?
     "allowed" : "denied"; // allowed, т.к. администратор обладает всеми привилегиями

echo $acl->isAllowed('administrator', null, 'update') ?
     "allowed" : "denied"; // allowed, т.к. администратор обладает всеми привилегиями