Zend Acl - модули, контроллеры, действия и модели

Я потратил день на поиск руководств и ответов о том, как реализовать Zend_Acl здесь, в SO, как и на других сайтах. И у меня заболела голова. :ИКС

Я видел, как люди использовали его, чтобы разрешить или запретить доступ к определенным контроллерам / действиям, а другие говорили, что этот способ неверен и должен разрешать или запрещать доступ на основе моделей. Да, второе кажется возможным, однако это означает, что для каждого контроллера мне нужна модель? Потому что кажется, что, следуя второй альтернативе, я смогу заблокировать доступ пользователя только в тот момент, когда он, например, редактирует сообщение. Но я бы хотел предотвратить доступ к действиям контроллера, редактирующего сообщение.

Если я хочу заблокировать доступ пользователя с ролью X к действию Y контроллера Z, как я буду это делать, если буду следовать второй альтернативе?

Было бы очень приветствовать пример реального приложения.

Эта информация может улучшить ваши ответы: Я использую Doctrine 2 как ORM, и у меня есть модуль Admin. Фактическая структура моего приложения такова:

application
  - MYAPP
    - configs
    - controllers
    - layouts
    - views
    - library
       - MYAPP ;This folder is in the include path
    - modules
       - admin

php model-view-controller doctrine-orm zend-framework zend-acl
person jonathancardoso    schedule 11.06.2011    source источник
comment
чувак - тебе нужно предоставить дополнительную информацию. Какая у вас конфигурация ACL для вашего конкретного случая. Я ожидаю, что вы добавите несколько фрагментов кода, чтобы мы могли понять ваш вопрос.   -  person emeraldjava    schedule 12.06.2011
comment
@emeraldjava, у меня нет актуальной конфигурации ACL, как я уже сказал, меня не смущают различные существующие реализации. Вот несколько ссылок, которые я читал, и, как видно, они идут разными путями: weierophinney.net/matthew/archives/ и stackoverflow.com/questions/2046608/.   -  person jonathancardoso    schedule 12.06.2011

Ответы (1)


arrow_upward
5
arrow_downward

Признаюсь, что я не Zend_Acl эксперт, но для меня суть использования Zend_Acl заключается в определении ролей, ресурсов и привилегий. Роли обычно довольно очевидны. И как только вы четко определили ресурсы, привилегии часто становятся очевидными.

Итак, для меня ключом является идентификация ресурса.

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

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

Не совсем прямой ответ на ваш вопрос. Скорее совет, чтобы быть верным своему собственному прочтению ситуации.

person David Weinraub    schedule 12.06.2011
comment
полностью согласен, вы можете закончить с разными уровнями ресурсов в зависимости от модулей (модуль разрешен / запрещен), затем для других модулей вы можете запретить доступ на основе контроллеров, затем для других по действиям, а для других по моделям и т. д. создать несколько независимых объектов Acl (и кэшировать их) для каждой политики (обычно полезно иметь 1 политику на модуль) - person regilero; 12.06.2011
comment
Спасибо за ответ. @regilero Вы говорите, что если у меня есть несколько типов ресурсов, мне нужно будет определить ACL для каждого (один на основе контроллеров, а другой на основе моделей)? - person jonathancardoso; 12.06.2011
comment
@Jonathan: да, вы МОЖЕТЕ, это не значит, что вы ДОЛЖНЫ, но вы должны попытаться иметь несколько объектов Acl, если вы хотите применить несколько уровней проверок ACL, чтобы они оставались маленькими, понятными и тестируемыми (и кешируемыми - иногда большими Объекты ACL с большим количеством правил должны даже быть разделены по ролям). - person regilero; 14.06.2011