Zend Framework: Можете ли вы использовать ACL без каталога плагинов?

Вам не нужно размещать acl.php в каталоге библиотек как плагин. Автозагрузчик отлично загрузит класс, уловка с Zend_Acl заключается в том, чтобы просто заполнить экземпляр класса вашими ролями и ресурсами.

Прошло немного времени с тех пор, как я прикоснулся к Zend Framwork, но я постараюсь направить вас в правильном направлении.

1. В начальной загрузке создайте объект Zend_Acl

   $ acl = новый Zend_Acl (); // см. документацию о том, как добавлять роли и ресурсы

2. Теперь создайте папку плагинов в каталоге вашего контроллера, это позволит вам аутентифицироваться с помощью вашего acl.

3. Внутри создайте новый класс, который расширяет Zend_Controller_Plugin_Abstract, присвойте ему правильное имя класса, которое будет подбираться автозагрузчиком.

4. Сохраните созданный вами ACL в реестре и в своем плагине переопределите метод preDispatch, отсюда у вас будет доступ к запросу и ACL (из реестра zend), которые вы можете проверить при необходимости. (Некоторые люди используют контроллер / действие в качестве ресурсов для других моделей. Это совершенно произвольно.

5. Зарегистрируйте свой плагин с помощью переднего контроллера.

   $ frontController-> registerPlugin (новый My_Controller_Plugin_Acl ());

Вероятно, это то, что предлагают другие руководства (или варианты этого), иногда это может немного сбивать с толку.

Никогда не следует добавлять файлы в каталог библиотеки Zend - есть ли у вас какие-либо ссылки на руководства, в которых это рекомендуется? Файлы должны находиться либо в каталоге библиотеки в пространстве имен вашего приложения, что дает вам такую ​​структуру, как:

application/
library/
    Zend/
        (ZF files)
    Foo/
        Controller/
            Plugin/
                ...

или в application/plugins, application/controller/helpers или в другом месте, в зависимости от вашего подхода.

Изменить: похоже, что в руководстве рекомендуется плагин контроллера, и в этом случае вам понадобится класс типа Yourapp_Plugin_Acl (замените Yourapp пространством имен вашего приложения), который будет жить по адресу application/plugins/Acl.php.

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

Но подумайте, что вы сбиваете с толку создание экземпляра своего ACL и запрос вашего ACL.

Скорее всего, вы создадите / заполните свой объект ACL во время начальной загрузки и сохраните его в Bootstrap реестре или в синглтоне Zend_Registry.

Если ваши ресурсы являются контроллерами, а ваши привилегии - действиями, то обычно перехватывают цикл отправки с помощью preDispatch() подключаемого модуля, который запрашивает ваш объект ACL.

Итак, мы действительно смотрим на два разных класса / объекта:

1. Один из них - это сам ACL, расширяющий Zend_Acl. Этому можно было бы присвоить имя Application_Model_Acl и поместить в файл application/models/Acl.php.

2. Другой - плагин фронтального контроллера. Этому можно было бы присвоить имя Application_Plugin_Acl и сохранить в файле application/plugins/Acl.php.

[Обратите внимание, что оба из них предполагают, что мы используем пространство имен приложения Application. Также обратите внимание, что оба они зависят от проекта.]

Конечно, описанному плагину необходимо предоставить объект ACL, чтобы он выполнял свою работу, поэтому у вашего Bootstrap может быть такой метод:

protected _initAclPlugin()
{
    $acl = new Application_Model_Acl();
    $plugin = new Application_Plugin_Acl($acl);
    Zend_Controller_Front::getInstance()->registerPlugin($plugin);
}

Но помните, что это только один способ использовать ваш ACL. В некоторых случаях ваш ACL может не ограничиваться только контроллерами / действиями. В этом случае вам может потребоваться передать свой объект ACL другим моделям / службам, которые также запрашивают его. В этом случае у вас может быть отдельный метод в вашем Bootstrap для создания вашего объекта ACL и сохранения его в Bootstrap реестре. Затем ваши контроллеры - или даже система внедрения зависимостей - могут захватить его оттуда и передать всем последующим моделям / службам, которые могут в нем нуждаться.

[Вы знаете, глядя на мой ответ, он не особо отличается от ответа @linead. Та же идея, разные слова, но он полностью вошел первым.]