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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

и т.д.

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

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

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

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