Как объединить несколько списков ACL в Zend Framework? - PullRequest
0 голосов
/ 16 декабря 2010

У меня есть несколько экземпляров Zend_Acl объектов, таких как этот (один для каждого модуля):

class My_Acl_Module1 extends My_Base_Acl
{
    public function __construct()
    {
        parent::__construct();
        $this->addResource('News_Model_Entry');
        $this->deny('guest', 'News_Model_Entry', 'index', new News_Model_Acl_Assert_CategoryPrivate());
    }       
}

class My_Base_Acl extends Zend_Acl 
{
    public function __construct()
    {
              $this->addRole('guest');
    }
}

Как объединить их в один объект ACL для использования в контейнере навигации?

Редактировать

Дополнительная информация:

  • Я не использую ресурсы контроллера в пользу ресурсов на основе моделей (модели, формы реализуют Zend_Acl_Resource_Interface). Все они имеют метод isAllowed()
  • Я использую модульный каталог и повторно используемые модули (отдельные модели, конфиги, маршруты и т. Д.)
  • Моему приложению известны все установленные модули, контроллеры, действия (структура уже проанализирована, не в режиме реального времени)

Итак, я ищу способ следовать этой схеме и отделить ACL для каждого модуля. Я не хочу использовать ресурс приложения, потому что это пустая трата времени - acl нужен не всегда.

У меня есть помощник действий, который создает конкретный ACL для модуля только тогда, когда он действительно нужен. Но иногда я хотел бы также иметь доступ к глобальному ACL приложения (например, когда я хочу передать его помощнику вида навигации или плагину контроллера).

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

Есть предложения?

1 Ответ

0 голосов
/ 16 декабря 2010

Я думаю, что это почти невозможно, если приложение не знает о себе немного больше. Недавно у меня была похожая проблема, и я не нашел удовлетворительного решения. При объединении вы потеряете некоторую информацию (модуль), которая понадобится вам позже в навигации.

Первое решение, которое у меня было, заключалось в том, чтобы перебрать все acl-файлы в каждом модуле и создать пользовательскую функцию ACL-merge для объединения их всех. Это действительно сработало, но мне не понравилась идея сканирования файла по всему моему приложению (даже если результаты были кэшированы).

Мой последний подход заключался в добавлении дополнительных данных в мое приложение: для каждого связанного действия я определял соответствующий acl-файл. Это было не так много работы, как может показаться. Главным образом потому, что мои контроллеры / модели действительно совпадают. Итак, у меня есть модель «Новости» и контроллер «Новости», который обрабатывает доступ к ней и отображает каждое действие модели на внешний интерфейс. Так что мне осталось только указать отношения acl / controller. (Я использовал пользовательский элемент в каждом контейнере навигации, чтобы сохранить это).

...