ACL

L!MP, хозяина по сути не сложно получить, ведь то же фото логично загружать с указанием кто загрузил

L!MP (17.09.2012/22:36)
AlkatraZ, я просто думал что ты там писал о исключительных ситуациях, таких как, например: фото, его может CRUD`ить не только админ состав, но и хозяин фотографии.
Это в роли не запихнёшь.

Такое модуль должен отрабатывать сам.
Однако, если уж делать полноценный ACL, и им будет управлять специальная функция, то все же желательно, чтоб модуль сообщал системе, какие есть "унаследованные" привилегии для авторов.
Пример: автор может быть в бане и на этот период ему запрещено что-либо делать.
Хотя, с другой стороны, информация о бане доступна всем модулям и они уже сами могут отрабатывать как себя в этом случае вести.

Но я думаю, чтоб не усложнять систему, можно просто добавить еще одну системную роль, это limited_user

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

AlkatraZ, можно просто в ACL ввести исключения:

ACL::allow($user->role, 'photo.edit', function() use ($user, $photo) {
    return $user->id === $photo->id;
});

AlkatraZ (17.09.2012/22:11)
А вот тут неверно. Как же ты узнаешь привилегии, если не знаешь, к какой группе относится юзер?

Не так выразился) имел в виду проверяется наличие привилегии в определённой группе.

L!MP, Думаю в направлении шаблона - "Цепочка обязанностей" - но что то сомневаюсь.
По сути объектная реализация предполагает либо:
1. Использование полиморфных классов при реализации функциональности - один класс для админа, который, соответственно, имеет админскую функциональность, один для пользователя и т.д. Можно так же воспользоваться шаблоном - Стратегия;
2. Инкапсуляция роли в объект и полиморфная замена роли, при этому коду будет как то параллельно с какой ролью он работает, роль сама подстраивает код под себя.

Вообще меня очень смущает if-else скрипт, реагирующий на роли. То есть:

if($role == 1){
  ...
}
elseif($fole == 2){
  ...
}
...

Расширение или сужение ролей потребует переписывание кода. Да, такой код будет более гибким в плане возможной реализации, но он тесно связан с самим понятием Роли. А что, если необходимо добавить возможности модеру или юзеру? Или убрать их? Сразу лезть в довольно большой скрипт (скажем форума) и копаться в нем.

В своей системке я реализовал все несколько иначе. Есть модуль, на пример Forum, контроллер данного модуля имеет набор доступных методов, скажем:
addMessage,
deleteMessage,
updateMessage
и др.

Эти методы изначально доступны всем пользователям системы, но благодаря модулю разграничения прав доступа можно определить роли и права доступа к методам всех модулей. Это выглядит примерно так: есть стандартные роли: Default user role (гость), User role (зарегистрированный пользователь), Administrator role (администратор) - есть так же дополнительные роли, определяемые самим модулем при его установке.
Каждая роль имеет неограниченное число прав доступа, на пример роль Default user role имеет такие права доступа:
Forum::addMessage, Forum::deleteMessage, Forum::updateMessage. Это означает, что если незареганый пользователь обратиться к любому методу контроллера модуля Forum, то доступ ему не дадут. Роль User role имеет такие права: Forum::deleteMessage, Forum::updateMessage - то есть обычный пользователь может только добавлять сообщения. Соответственно у админа нет никаких ограничений, то есть роль Administrator role не расширена правами доступа на модуль Forum.

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

С другой стороны, есть модуль определяющий права доступа на уровне не модели, а представления - Visibility - данный модуль отвечает за отображения тех или иных компонентов пользовательского интерфейса. То есть простой пользователь не видит кнопок админа и т.д. Если же он путем JS отправит запрос на уровень модели в обход модуля Visibility, то запрос будет запрещен модулем Access, который я описал выше.

В частности модуль Visibility работает аналогично модулю Access с той лишь разницей, что запрещает доступ к экранам, а не методам контроллеров. Создаются отдельные экраны для админа и пользователя, а пользователю запрещается видить экран админа. Если он запросит его, то система сообщит о 404.

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

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

тoecть этo мнe нaдo бyдeт имeть cпиcok мeтoдoв мoдyля и пoтом дaю дocтyп poлям k ним?
т.e y мeня ecть poль юзep - дaю eмy дocтyп к мeтoдy чтeния и зaпиcи тak?