Проектирование системы прав...

[Духовность™]

Проектирование системы прав...

У меня стоит не совсем обычная задача. Нужно сделать систему прав на модули сайта.

Теоретически это все легко делается. Есть модуль. У модуля есть действия. Создаю группу, даю этой группе права на модули и\или их действия.

Но задача немного усложнена. Дело в том, что пользователям необходимо давать доступ не только на какие-то модули, но и на то, что эти модули создают.

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

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

Т.е. имеется явное разграничение прав - права на физический модуль, который изначально создает какие-то функции (гостевая, новостная лента), а также права на виртуальные модули ("гостевая книга васи", "гоствевая книга пети").

Как более логично организовать такую систему? Кто что может посоветовать (если кто чего ещё понял )?

 

[boombick]

google:// acl

 

[Alexandre]

Т.е. имеется явное разграничение прав - права на физический модуль, который изначально создает какие-то функции (гостевая, новостная лента), а также права на виртуальные модули ("гостевая книга васи", "гоствевая книга пети").

также права на виртуальные модули = права на сам модуль + право на использовании сегмента данных ("гостевая книга васи" id= 3 , "гостевая книга пети" id= 5 : access data in (3,5) ).

 

[Духовность™]

Alexandre
хм.. понятно..

модуль, создающий гостевую книгу, и модуль редактирования сообщений в гостевой - это разные модули по сути? Если да, то

также права на виртуальные модули = права на сам модуль + право на использовании сегмента данных

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

 

[Alexandre]

права на виртуальный модуль - это право на редактирование\удаление сообщений в гостевой. так?

это как ты построешь свою систему.

есть право доступа к модулю : редактироване гостевой
есть право на доступ к данным ( данные дяди васи и дяди пети)

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

 

[Духовность™]

Alexandre
понял.так и сделаю. спасибо

 

[baev]

Есть субъект, объект и действия субъекта в отношении объекта.

triumvirat, посмотрите это:
http://www.postnuke.ru/index.php?module=subjects&func=viewpage&pageid=43
— там есть права (по возрастанию) на чтение, комментирование, редактирование, удаление, администрирование. Это и есть действия. Как именно они реализуются — через «админку» или «фронтенд» — значения не имеет.
Имеет значение то, что нет необходимости «наделять юзера двумя видами прав», так как «вышестоящие» права включают в себя «нижестоящие» (вполне логично, что если у пользователя есть право комментировать новость, то уж и прочитать её ему должно быть позволено).

 

[Духовность™]

baev
Спасибо, обязательно изучу.

 

[korchasa]

Автор оригинала: baev
Есть субъект, объект и действия субъекта в отношении объекта.

triumvirat, посмотрите это:
http://www.postnuke.ru/index.php?module=subjects&func=viewpage&pageid=43
— там есть права (по возрастанию) на чтение, комментирование, редактирование, удаление, администрирование. Это и есть действия. Как именно они реализуются — через «админку» или «фронтенд» — значения не имеет.
Имеет значение то, что нет необходимости «наделять юзера двумя видами прав», так как «вышестоящие» права включают в себя «нижестоящие» (вполне логично, что если у пользователя есть право комментировать новость, то уж и прочитать её ему должно быть позволено).

Наследование привилегий не есть гуд. Например запись в блоге, которую можно оценивать. Автор может редатировать, но не может голосовать. Остальные - наоборот.

Простой ACL: ресурс(с наследованием, если необходимо), роль (чаще всего с наследованием) и привилегии.

Посмотрите на реализацию Zend_Acl. Единственное, чего ей не хватает привилегий на отдельные инстансы ресурсов и ролей. Но это легко исправить, если сами классы ресурсов будут иметь какой-ниубдь метод, типа:

class BlogEntry implements DynamicResource
{ 
    ...
    function getUserRoleId($user) {
       return ($user->getId() === $this->getOwner()->getId()) ? 'owner' : 'user';       
    }
}

тогда в ACL можно защить, что если у него спрашивают доступ к сущности класса, имплементирующего интерфейс DynamicResourse, то определять роль пользователя, через вызов getUserRoleId().

 

[baev]

Автор может редатировать, но не может голосовать.

Зачем «мешать мух с котлетами»?
Голосование — это отдельный «модуль», со своими собственными объектами.
В «модуле» блогов объект — запись в блоге.
В «модуле» голосований объект — оценка чего-либо (не обязательно записи в блоге). И нормально всё наследуется.

 

[korchasa]

Автор оригинала: baev
Зачем «мешать мух с котлетами»?
Голосование — это отдельный «модуль», со своими собственными объектами.
В «модуле» блогов объект — запись в блоге.
В «модуле» голосований объект — оценка чего-либо (не обязательно записи в блоге). И нормально всё наследуется.

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

Просто не очень понятно зачем все эти модули, и ограничения с этим связанные. По идее использование в роли ресурса любого объекта гораздо удобнее, ибо можно наложить ACL абсолютно на любой объект. Для этого он должен реализовать всего 1 или 2 метода (в зависимости от своей природы). Ну это уж, наверное, кому как удобнее.

 

[Духовность™]

Просто не очень понятно зачем все эти модули, и ограничения с этим связанные

сайт будет давать площадку различным людям и организациям