Как я могу реализовать множественное наследование среди ресурсов в Zend Acl? - PullRequest
3 голосов
/ 14 мая 2009

Короче говоря: почему 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, ответьте также!

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

Ответы [ 2 ]

4 голосов
/ 15 мая 2009

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 15 мая 2009

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

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

В конце статьи рассказывается о том, как разрешить доступ на чтение для всех ресурсов и создать общие правила разрешения / запрета.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...