Где реализовать Zend_ACL с объектами домена и Data Mapper?

Здесь есть согласие (внимательно прочтите ответ @teresko), что ACLs лучше всего вписывается в Шаблон декоратора (контейнер безопасности).

Если определения привилегий вашего ACL хранятся в базе данных, тогда у вас должен быть DataMapper для сопоставления между определениями acl в вашей базе данных и вашей фактической реализацией объекта Zend_Acl с его resources, roles и privileges.

Вероятно, вы не будете реализовывать с помощью декораторов контроллеров из-за природы ZF 1 (множество антипаттернов, глобального состояния и т. Д.). Вместо этого вы будете использовать сквозные проблемы с плагином (preDispatch), который проверяет его за вас. Итак, ваш ACL должен быть одним из первых инициализированных объектов.

Учитывая, что ваши определения ACL основаны на именах controller и action, ваш плагин вызовет ваш AclMapper, чтобы получить заполненный объект ACL, а затем проверит, разрешен ли текущий пользователь доступ к данному ресурсу.

Проверьте этот пример кода:

class Admin_Plugin_AccessCheck extends Zend_Controller_Plugin_Abstract 
{
    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        if($request->getModuleName() != 'admin')
        {
            return;
        }


        $auth = Zend_Auth::getInstance();
        $action = null;

        if(!$auth->hasIdentity())
        {
           $action = 'login'; 
        }
        else
        {
            /**
             * Note that this is not a good practice (singletons). 
             * But in this case it's avoiding re-loading the Acl from database
             *  every time you need it. Also, considering that ZF 1 is full of 
             * singletons, it'll not hurt, I think ;)
             * YOU CAN CHANGE THIS LINE TO $aclMapper->getAcl();
             */

            $acl = Acl::getInstance();

            $resource = $request->getModuleName() . ':' . $request->getControllerName();
            $privilege = $request->getActionName();

            $identity = $auth->getStorage()->read();
            $role = $identity->role_id;

            if($acl->has($resource))
            {
                if(!$acl->isAllowed($role,$resource,$privilege))
                {
                    $action = 'access-denied';
                }
            }
        }

        if($action)
        {
            $request->setControllerName('authentication')
                    ->setActionName($action)
                    ->setModuleName('admin');
        }
    }
}

@Question # 1: Нет, ACL не принадлежит вашим картографам. Помните о разделении проблем. Если вы решите основывать свой ACL на основе каждого объекта, подход декоратора, как указано выше, - ваш путь. Однако декоратор вполне может быть реализован вокруг картографа. Рассмотрим эту acl-структуру, предоставленную ZF1: resource: your Domain-entity, например classname role: привилегия роли пользователя: C-R-U-D

<?php
class SecurityContainer {
    /**@var Zend_Acl*/
    protected $acl;

    /**@var DataMapper */
    protected $mapper;

    /**@var User|rolename*/
    protected $user;

    public function __construct($acl, $mapper, $user) {
        $this->acl = $acl;
        $this->mapper = $mapper;
        $this->user = $user;
    }

    public function __call($method, $entity) {
        if (method_exists($this->mapper, $method) {
            if ($this->acl->isAllowed($user, get_class($entity), $method) {
                $this->mapper->$method($entity);
        }
    }
}

Это приводит к вопросу 2: Это действительно зависит от того, как вы разработали интерфейс приложения. Если есть одно действие для каждой CRUD-операции каждого типа сущности, вы можете реализовать свой acl просто с помощью FrontController-Plugin, как показывают многие и другие учебные пособия для ZF1. Если вам нужен более детализированный ACL, скажем, роль GUEST может обновлять название компании, но менеджер может обновлять всю сущность, или если у вас есть действия, в которых изменяется более одной сущности, подход на основе сущностей является имо лучше.

Некоторые другие мысли о дизайне, который вы обрисовали: я не думаю, что это хорошая идея позволять сущностям проверять себя. Попробуйте реализовать решение, в котором тип проверяется конкретным валидатором. Вы даже можете снова использовать декоратор;) Это все равно было бы более чистым решением.

Есть причины, по которым вы не должны использовать свои картографы внутри действий контроллера. Во-первых, становится все труднее проводить приемочные тесты, которые не связаны с вашей базой данных (хотя это зависит от вашей реализации). Вы указали на другого: делайте свои действия как можно короче. С ACL и валидаторами ваше действие станет больше. Рассмотрите возможность реализации Servicelayer, как указано в другом вопросе @teresko. Это также будет полезно для ACL на основе свойств, если вам это нужно.

Надеюсь, это вам как-то помогло.