Традиционный подход для управления доступом к действиям контроллера - это создание ресурса (строкового идентификатора) для каждого/модуля/контроллера/действия, а затем проверить ACL в плагине контроллера.ACL на основе ресурсов и ACL на основе контроллера
В последнее время я обнаружил очень удобный Zend_Acl_Resource_Interface, который может использоваться для контроля доступа к любому классу, реализующему его. Таким образом, любая модель, форма или другой элемент приложения может стать ресурсом ACL. Это довольно здравый подход, потому что таким образом ресурсы приложений становятся ресурсами ACL.
Это очень легко с слушателями Doctrine, поэтому мне вообще не нужна никакая дополнительная логика в контроллере.
Теперь я могу проверить ACL, например. всякий раз, когда любая форма создается и в конечном итоге перенаправляется на страницу входа.
Но как я могу скрыть элементы навигации Zend, которые используют ограниченные формы, модели и т. Д.
Нужен ли мне традиционный подход, ориентированный на контроллер? Нужен ли мне отдельный идентификатор ресурса для каждого элемента навигации? В чем же преимущество использования ACL на основе ресурсов?
Спасибо, но вы должны внимательно прочитать вопрос. Рассмотрим следующую ситуацию: у меня есть страница */create * с двумя формами (например, поиск и создание), их идентификаторы ресурсов * seach-resource * и * create-resource *. Какой я должен использовать в навигации? Мне все еще нужно создать новый ресурс для доступа к URL ... – takeshin
Да, я упускаю из виду некоторые случаи. – ngsiolei