Как мне структурировать свое дерево ресурсов в ACL? - PullRequest
4 голосов
/ 15 июня 2009

Используя PHP и Zend_ACL, я хочу создать чрезвычайно гибкую систему разрешений. Я хочу иметь возможность назначать разрешения всем объектам определенного типа, а также экземплярам этих объектов. Если запрашивается конкретный экземпляр объекта, и он не существует в дереве ресурсов, то можно использовать набор разрешений для «универсального» объекта. Моя проблема в том, что это необходимо для вложения, и я не могу найти способ сделать это без множественного наследования, которое не поддерживает Zend_ACL.

Примером может быть это. Онлайн учебный сайт с факультетами, курсами и мероприятиями. Каждое событие относится к курсу, а каждый курс к факультету. Я хотел бы иметь возможность разрешить каждой роли факультета доступ ко всем курсам (и событиям по наследству), но определенный факультет хочет, чтобы их материал был закрытым. Поэтому в структуре моего дерева ресурсов есть узел ресурса для каждого факультета и каждый курс, принадлежащий к этой ветви факультета от узла факультета, вместо ветви от общего узла курса, который дает каждому курсу свои разрешения по умолчанию. С новой структурой, как я могу применить свои общие разрешения курса? То же самое касается событий ниже курсов, если я хочу, чтобы каждое событие было доступно для чтения, только если родительский курс доступен для чтения, но я также хочу применить набор разрешений по умолчанию для каждого события, как я могу организовать дерево так, чтобы каждое событие наследовало от его родителя, и это общий узел без множественного наследования?

Любые вопросы, комментарии или предложения по другой системе приветствуются.

Ответы [ 2 ]

2 голосов
/ 11 августа 2009

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

Вы не хотите, чтобы курс наследовал права факультета напрямую; Вы, вероятно, захотите, чтобы кто-то мог редактировать курсы для этого факультета (ТП или что-то в этом роде), но не сам факультет, верно?

факультетов, курсов и мероприятий. каждый событие принадлежит курсу, и каждый курс на факультет

Parent -> middleman -> child
Courses -> Courses:Faculty2 -> Courses:Faculty2:Course1 
Events -> Events:Course1 -> Events:Course1:Event3

и т.д.

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

Если вы хотите, чтобы все события для определенного курса были скрыты - вы просто устанавливаете разрешение для Event: Course #

Если вы хотите иметь возможность устанавливать разрешение на все события факультета, вы можете просто добавить другого «промежуточного» родителя над Event: Course1, который также группирует события по факультетам: Events:Faculty2:Course1:Event3

Я обнаружил, что для системы разрешений 9 раз из 10 вам не нужно (или не нужно путаница) множественное наследование. Если ваш контроль доступа более сложен, чем простое дерево, вам следует пересмотреть свой контроль доступа.

0 голосов
/ 15 июня 2009

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

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

...