Как мне структурировать свое дерево ресурсов в ACL?

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

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

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


person Community    schedule 15.06.2009    source источник
comment
Похоже: stackoverflow.com/questions/890068/   -  person gnarf    schedule 12.08.2009


Ответы (2)


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

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

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

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

и т.д

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

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

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

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

person gnarf    schedule 11.08.2009

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

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

person Elzo Valugi    schedule 15.06.2009
comment
Я не вижу способа приспособить свои требования к текущей системе. Я хочу иметь возможность определять набор правил по умолчанию для каждого типа объекта, но также давать определенные правила для экземпляров этих объектов, сохраняя при этом наследование между типами и экземплярами. Это означает, что идентификатор события № 4 наследуется от экземпляра родительского курса, а также тип события по умолчанию. - person ; 15.06.2009
comment
На факультетах, курсах и мероприятиях Zend_ACL все они являются ресурсами и наследуются друг от друга. Допустим, у нас есть 2 роли: инсайдер и аутсайдер. Когда вы строите свое дерево ACL, вы по умолчанию разрешаете доступ всем инсайдерам и закрываете весь доступ посторонним к тем же ресурсам. Это будет вашим поведением по умолчанию. Теперь, если вам нужно какое-то особое поведение для роли / ресурса с учетом дополнительного условия вашего именования, вы просто подключаете утверждение к правилу. Если утверждение выполняется, у вас есть исключение из общего правила, в противном случае выполняется обычное правило. - person Elzo Valugi; 16.06.2009
comment
Я играл с утверждениями, и я думаю, что они будут работать, однако проектирование и интерфейс, позволяющий их применять, будут очень сложными. Кроме того, zendframework.com/issues/browse/ZF-1721 не позволяет мне делать то, что Хочу с утверждениями (нетривиальные вещи). Как вы думаете, я могу развернуть Zend Framework с исправлениями? - person ; 16.06.2009
comment
Я бы не рекомендовал, если только это не простой проект. В долгосрочной перспективе все пойдет еще сложнее и запутаннее. Я уже пробовал этот путь с другими ошибками. Если расширение текущего класса ACL для вас не вариант, возможно, вам следует создать свою собственную систему ACL. - person Elzo Valugi; 17.06.2009