Как я могу реализовать множественное наследование среди ресурсов в Zend Acl?

Короче говоря: почему Zend ACL поддерживает множественное наследование между ролями, а не ресурсами?

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

Пример:

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

Итак, упомянутое выше дерево дженериков будет выглядеть так:

                        module
                    /     |     \
                  user  forum  gallery
                  /       |       \
               profile   topic    photo
                          |
                         post

И дерево экземпляров будет выглядеть так:

                        module_1
        /     /     /      |           \        \           
    user1 user2 user3     forum     gallery1    gallery2
      |     |     |       /   \       /   \       /   \ 
profile profile profile  sub1 sub2  photo photo photo photo
                         |     / \
                     post1 post2 post3 

И в ACL каждый экземпляр объекта пользователя будет унаследован от пользователя в первом дереве. Так что по умолчанию я хочу, чтобы все было доступно для чтения, поэтому я разрешаю читать в модуле. Все наследуется от модуля, так что все в порядке. Я также хочу, чтобы пользователи могли редактировать свои профили, поэтому я предоставляю редактирование каждому пользователю в соответствующем профиле, дерево универсальных шаблонов здесь не помогает. Допустим, мои фотогалереи - NSFW, поэтому я не хочу читать о них. При множественном наследовании я могу запретить чтение фотографии любому незарегистрированному пользователю, и это всего лишь одна операция. Без множественного наследования мне приходится просматривать каждую фотографию и отказывать незарегистрированному пользователю в праве на чтение. Если у меня много фотографий, это плохие новости.

Кто-нибудь знает, как это сделать? Это самое гибкое решение, которое я могу придумать. Если вы можете придумать что-нибудь получше, которое можно реализовать с помощью Zend_Acl, ответьте также!

Большое спасибо.


person hornairs    schedule 14.05.2009    source источник


Ответы (2)


Во-первых, чтобы ответить на ваш вопрос re. множественное наследование ресурсов. Zend_ACL не поддерживает это, потому что ваше дерево ресурсов предназначено для репликации физических ресурсов, которые вы защищаете. Вы просто не можете (например) иметь файл более чем в одном родительском каталоге.

Итак, чтобы предоставить вам решение ...

  • Я предполагаю, что ваше дерево «дженериков» - это ваши ресурсы.

  • Ваши роли должны представлять ваши группы пользователей: анонимные, зарегистрированные, модераторы, администраторы и т. Д. Каждая более разрешающая роль должна наследовать от предыдущей, так что «зарегистрированные» наследуются от «анонимных», «модераторы» - от «зарегистрированных» и т. Д. Это позволяет каждый уровень должен иметь все права своего родителя, а затем добавить некоторые.

  • Предполагая, что вы используете структуру, подобную описанной мной, вы также должны использовать привилегию для назначения возможных действий пользователя. т.е. "просмотр", "редактирование", "добавление" и "управление" см. текст ссылки

  • Вам необходимо назначить права «просмотра» анонимной роли в «модуле», предоставив всем доступ на чтение.

  • Вам необходимо назначить права «добавить» зарегистрированной роли на «форуме», дав там права на чтение (унаследованные от анонимной роли) и добавление для зарегистрированных пользователей.

  • Вам необходимо назначить права «добавить» зарегистрированной роли в «галерее», указав там права на чтение (снова унаследованные) и добавление для зарегистрированных пользователей.

  • Промыть и повторить для модераторов, админов и т. Д. И т. Д.

  • Чтобы позволить пользователю изменять свой собственный профиль, загружать изображения и т. Д., Вы не должны использовать ACL для обработки взаимодействий на этом уровне. Просто создайте метод isOwner для любых объектов, представляющих ресурсы (объект изображения, объект профиля и т. Д.), Который будет возвращать логическое значение в зависимости от того, владеет ли текущий вошедший в систему пользователь этим элементом. Таким образом, вы можете решить, разрешать ли этому пользователю редактировать / удалять / т. Д. Этот профиль / изображение.

Надеюсь, это будет полезно!

person antz29    schedule 14.05.2009
comment
Спасибо за ответ! Я вижу, что файл не может принадлежать нескольким каталогам, но в моем приложении есть экземпляры, в которых ресурсы принадлежат нескольким родителям. Это плохая практика? У меня есть модуль сообщества в приложении, чтобы добавить немного изюминки социальных сетей, и их несколько, а иногда и много администраторов. Я подумал, что лучше оставить это простой проверке ACL, хранящейся в сеансе, вместо того, чтобы перестраивать список разрешенных администраторов каждый раз, когда происходит действие редактирования. Я согласен с тем, что метод isOwner проще, но менее гибкий, и мне пришлось бы переписывать его для каждого модуля. - person hornairs; 19.05.2009
comment
Обычно это будет считаться плохой практикой, но только потому, что это может немного сбивать с толку. Если вы хотите поговорить о своем дизайне в целом, возможно, я смогу помочь ... - person antz29; 22.05.2009
comment
Я до сих пор не заставил это работать. Требования выходят за рамки потребности в простом методе isOwner (или утверждениях) для определения разрешений для категорий сообщений. Как ты думаешь, мы могли бы поболтать? - person hornairs; 15.06.2009

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

Если бы я писал код ACL сейчас, я бы, наверное, взглянул на эту статью о типах ресурсов ACL по адресу http://codeutopia.net/blog/2009/02/11/zend_acl-part-2-different.-roles-and-resources-more-on-access/ и, возможно, части 1 и 3 для вдохновения.

Ближе к концу статьи идет разговор о разрешении доступа для чтения ко всем ресурсам и создании общих разрешающих / запрещающих правил.

person David Snabel-Caunt    schedule 14.05.2009