Кто как реализовывал? у юзера есть список ролей, у которых есть разные уровни доступа. доступ высчитывается по их объединению. Роли могут быть вложены каскадом, есть таблица для развертывания каскада и хранения, чтобы не считать каждый раз. остается как минимум вопрос как была назначена роль и в какой момент ее снимать, чтобы не убить аналогичный доступ, выданный из другого места.
у меня стоит задача реализовать вот такие сложные права доступа: есть товары. Их можно просматривать, добавлять-редактировать-удалять; ксть разделы, тоже самое что и выше; атрибуты; наборы атрибутов; ... есть пользователь Вася. Уму нужно разрешить просматривать все, но редактировать он не должен. А есть пользователь Петя - он может и редактировать тоже есть я. Я как root - могу делать все + добавлять-удалять-редактировать прочих админов (но права у них будут меньше чем у меня). И как это можно сделать?
Koc 4 уровня доступа - пользователь, модератор, младший администратор, главный администратор. tinyint поле в бд с АйДи соответствующего уровня и при входе так же записываешь его уровень в свойства объекта. Потом, при вызове действия: if (User::Level(User::GrandAdmin) { тут действия разрешенные только главное админу. }
я считаю что лучшая структура управления такова users: id, login, password, is_locked groups: group_id, group_name allows: allow_id, allow_name allow2group: allow_id, group_id user2group: user_id, group_ id деление всех пользователей по группам. группы имеют права. право имеет номер. напр право 451 - редактирование системных настроек. если имеет его юзер - все ок и даем это делать)
Koc именно с помощью описанного мной алгоритма все это можно реализовать. то есть прав может быть бесконечное множество напр группа "Редакторы". имеют права удалять, добавлять, редактировать страницы В группе "редакторы" пользователи vasya,petya,john
а я контроллеру даю инициализировать только те экшоны, которые зарегистрированы у роли пользователя Гы)
короче объясняю популярно у каждой группы юзверей есть свои права, в таблице это может быть повсякому, мне удобно работать с сериализованным массивом такого вида array( "can_add_comments"=>1, "cannot_see_category"=>array("1","4","10") ........ ) При авторизации в сессию пишем $_SESSION['user']['rights']=$rights; где $rights десереализованный массив Как с этим работать, тут вариантов ещё больше У меня есть папочка с классами, в классах прописанны права для модулей, например PHP: <? class Rights_Comments { static function Can_AddComments(){ if($_SESSION['user']['rights']['can_add_comments'] || Rights_Sistem::Is_Admin()) return true; return false; } } ?> Другой класс PHP: <? class Rights_Sistem { static function is_admin(){ if($_SESSION['user']['info']['user_group']=='admin' || self::Is_Root()) return true; return false; } static function is_root(){ if($_SESSION['user']['info']['user_group']=='root') return true; return false; } } ?> Ну и далее, в модулях вызываю эти классы где надо Новые права добавляются путём добавления новых классов с общим интерфейсом, но это другая история
но это всё из-за того что у меня модульный движок, собирается по кусочкам, если у тебя статичный, создай один класс с правами, вон как у шока, и не парься
Могу заделится кусочком описания, как это делается «по большому», но в личку, т.к. проект чужой, хоть и моего авторства.
Mr.M.I.T. БОЛЬШОЙ минус твоего метода - имя (тег) права прописывается в коде а не в базе => рядовые пользователи не смогут добавить сами какой либо группе какое либо право. реализация у меня наоборот намного более гибкая и смотрит в счастливое будущее)
плюс ты создаешь туеву хучу классов (зачем тут ваще класс делать?). а у меня отправляется тока один запрос и возвращает тока один байт: 0 или 1
флоппик да мы в курсе, что такое воркбенч) У меня он установлен. Еще есть хорошая отечественная разработка на тему создания запросов/визуализации моделей зы: эх, все равно наверно сделаю не по-большому а как SeregA описал.
У меня примерно сделано как у SergeyA, только 4 таблицы - users, groups, permissons, perm2user_group и права проверяются как у Mr.M.I.T. PHP: <? if (Permission::isPermission('MODER_NEWS')) бла бла бла ?>
SeregA вообще-то в базе массив хранится, у тебя тоже самое только ты не массив хранишь, а создал ещё 3 таблицы лишних А толку то что он добавит а Одминке новое право? в системе то для его внедрения придётся лезть в коде рыться право у меня имеет право добавлять только система =) Для удобства выставления приоритетов у меня вообще не отправляется не одного
или ты имеешь ввиду не добавление новго права, а изменение прав группы? и с чего ты взял что у меня этого нельзя делать? с этого фактически всё начинается
Но все равно у меня более гибко. 1. У меня можно создавать бесконечное множество групп, не правя ни строки кода 2. У меня более интернациализированная система ) Т.е. в админке, в управлении пользователями можно переименовывать права и группы 3. Нет привязки к user, admin, root. кстати, нет такого слова "sistem"