Вводная

Общеизвестно, что кроме прочего плагины позволяют выполнять некий код до и после действия (action) контроллера. Именно тут и притаилась логическая бомба размеров чуть меньше среднего.

Обычно авторизация (определение возможности выполнения тех или иных деяний в зависимости от прав) помещается в Pre-обработчик:

class Application_Controller_Plugin_Auth extends Zend_Controller_Plugin_Abstract{
    public function preDispatch(Zend_Controller_Request_Abstract $request){
        /*
        ...
        */
    }
}

о выборе:

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

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

Плагин Zend_Controller_Plugin_ErrorHandler, включенный по-умолчанию, регистрирует Post-обработчик и выполняет аналогичные действия с перезаписью значений модуля, контроллера и действия, но в случае возникновения исключений.

об исключениях:

обычно в задачу этому плагину ставится отлов отсутствия вызываемого контроллера или действия, что можно рассматривать как ошибку №404, в то время как исключения внутри существующих действий как ошибку №500

Суть

Авторизация, в подавляющем большинстве конфигураций, пропустит нас к несуществующему действию. Однако обработчик ошибок чутко перенаправит на контроллер и действие (по-умолчанию error и error соответственно) по обработке ошибки, что в цикле диспетчеризации опять вызовет проверку авторизации. Если забыть прописать правила на доступ к контроллеру и действию обработки ошибок, мы будем повторно брошены на поиски несуществующего со всеми печальными последствиями: плагин ErrorHandler, почуяв мистический вызов себя второй раз, бросит неотлавливаемое уже никем (ясное дело, их отловом он и занимается) исключение и все будет потеряно.

к слову о перестраховке:

можно обернуть в try...catch вызов Zend_Controller_Front::getInstance () ->dispatch () чтобы ловить неотлавливаемое и там

Вывод и возможные решения

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

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

public function preDispatch(Zend_Controller_Request_Abstract $request){
    if ($this->_response->isException()) return;
    /*
    ...
    */
}

$filter = new Zend_Filter_Alnum(true);
Zend_Debug::dump($filter->filter('это странненько - mbstring enabled'));
//string(19) "   mbstring enabled"

$filter = new Zend_Filter_Alnum(true);
Zend_Debug::dump($filter->filter('это странненько - mbstring disabled'));
//string(48) "это странненько  mbstring disabled"

Данное поведение очень тесно перекликается с ошибочной фильтрацией умляутов, о которой было заявлено порядка месяца назад.

В свое время на phpclub.ru была опубликована статья с неплохим описанием модели, структурой таблиц и примерами. Также Максимом Матюхиным был приведен класс для работы с этой моделью. После возникшей потребности этот класс был переписан под Zend Framework. При «портировании» я просто заставил код немного по другому звучать и добавил некоторую функциональность из PEAR::DB_NestedSet.

Для работы с любыми классами производными от ZF-классов обычно рядом с директорией Zend, содержащей фреймворк, создается директория Application с аналогичной ZF иерархией — в этом случае Zend_Loader сможет подгрузить их в обычном порядке. Этим и обусловлено название класса — Application_Db_Table_Nestedset.

Код документирован и не является чем-то новым поэтому развернутый мануал по использованию приводить бессмыслено.

Доступ через хранилище или архивом.