Система привилегий « PHP для идиотов

Сообщения: 3131 Репутация: N Группа: в ухо

Окт. 13, 2007, 11:34 д.п.

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

Dagdamor

Сообщения: 47 Репутация: N Группа: Кто попало

Окт. 13, 2007, 1:24 п.п., спустя 1 час 49 минут 22 секунды

Разумеется, приводилось. Во всех проектах стараюсь использовать одно и то же решение - достаточно простое и в то же время достаточно мощное.
1. Таблица users - есть поле usergroupid (id группы). Поле обязательное.
2. Таблица usergroups - если список полей, начинающихся с префикса "can". Например canview, canwrite, caneditprofile.
3. Таблица userrights - список прав. Редактируется из админки. Добавляем право - в таблице usergroups появляется новое поле.

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

Как разрулить ситуацию "модератор такого-то раздела"? Очень просто. Для модераторов создается две отдельных группы. Одна, "номинальная" - это в которой по умолчанию сидят все модераторы сайта. Права у данной группы могут ничем особенно не отличаться от прав обычных пользователей, не-модераторов. И есть вторая группа "модераторов в действии". Эта группа, к которой модератор причисляется временно, только на тот момент, пока он находится в "своем" разделе сайта. У этой группы прописаны все необходимые права, например, право редактировать чужие сообщения.

md5

Сообщения: 11960 Репутация: N Группа: в ухо

Окт. 13, 2007, 4:24 п.п., спустя 3 часа 24 секунды

у меня права раздаются группа пользователей, на данном этапе меня это вполне устраивает
есть 4 вида действия view, add, edit, delete
по которым собственно и назначаются разрешительные и запрещающие действия
это всё для бэк-энда, т.е. для каждого модуля в бэк-энде прописываются нолики и единички
структура такая

  `id` int(11) unsigned NOT NULL auto_increment,
  `group_id` int(11) unsigned NOT NULL default '0',
  `module_id` int(11) unsigned NOT NULL default '0',
  `action_id` tinyint(2) NOT NULL default '0',
  `value` binary(1) NOT NULL default '0'

ну тут конечно с int(11) загнул, не спорю =))
вобщем, action_id – это от 0 до 3 действия
value – 0 или 1

для фронт-энда можно манипулировать только возможностью просматривать (на данном этапе опять же =) ) различные страницы

все умрут, а я изумруд

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

Окт. 13, 2007, 4:32 п.п., спустя 8 минут 6 секунд

мой вариант:

1. Таблица пользователей. Каждый пользователь относиться к определённой группе.
2. Таблица групп.
3. Таблица всех возможных привилегий
4. Таблица связи групп с их привилегиями (М:М)

чтобы пользователь мог принадлежать сразу нескольким группам - ещё одна таблица м:м

Dagdamor

Сообщения: 47 Репутация: N Группа: Кто попало

Окт. 13, 2007, 5:29 п.п., спустя 57 минут 19 секунд

md5
Timur
Давайте теперь сравним количество и типы запросов ;) У меня:
1-й запрос - получение данных о текущем пользователе: SELECT * FROM users WHERE id=$userid
2-й запрос - получение его прав: SELECT * FROM usergroups WHERE id=$user[usergroupid]
Итого 2 запроса, оба выбирают 1 строку по PK.

После этого проверка прав в приложении выглядит примерно так: if($usergroup["canview"]) …

md5

Сообщения: 11960 Репутация: N Группа: в ухо

Окт. 13, 2007, 6:14 п.п., спустя 44 минуты 12 секунд

давай не будем сравнивать, я те в личке могу объяснить 1 простую маленькую тайну! ;)

все умрут, а я изумруд

adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

Окт. 13, 2007, 7:09 п.п., спустя 55 минут

Dagdamor, мож так?

SELECT users.gid, usergroups.*  FROM users, usergroups WHERE users.id = $userid AND usergroups.id = users.gid;

https://smappi.org/ - платформа по созданию API на все случаи жизни

vasa_c

Сообщения: 3131 Репутация: N Группа: в ухо

Окт. 13, 2007, 7:13 п.п., спустя 4 минуты 35 секунд

Dagdamor, можно поподробнее? Запутался… :)

vasa_c

Сообщения: 3131 Репутация: N Группа: в ухо

Окт. 13, 2007, 7:33 п.п., спустя 19 минут 38 секунд

Timur,

Каждый пользователь относиться к определённой группе.

чтобы пользователь мог принадлежать сразу нескольким группам - ещё одна таблица м:м

Так всё таки в одной группе может пользователь состоять или в нескольких?

Dagdamor

Сообщения: 47 Репутация: N Группа: Кто попало

Окт. 13, 2007, 8:27 п.п., спустя 54 минуты 32 секунды

ad3000
Это будет ненамного быстрее/проще исходного варианта. :) Все равно идет выборка из двух таблиц по первичным ключам.

md5, давай! Мог бы сразу и написать.

Мне действительно интересно увидеть, как в других решениях происходит собственно анализ и раздача прав. Накидать таблиц - лишь полдела.

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

Окт. 14, 2007, 12:42 д.п., спустя 4 часа 14 минут 38 секунд

Так всё таки в одной группе может пользователь состоять или в нескольких?

т.е. я привёл вариант, когда пользователь состоит только в одной группе. Что бы можно было в нескольких, должна быть ещё одна таблица м:м (id_пользователей и id_групп).

2Dagdamor, согласен, в твоём случае запросы получаются короче и проще, но

2. Таблица usergroups - если список полей, начинающихся с префикса "can". Например canview, canwrite, caneditprofile.
3. Таблица userrights - список прав. Редактируется из админки. Добавляем право - в таблице usergroups появляется новое поле.

не пойму зачем вообще тогда таблица userrights если все её записи отражены в структуре usergroups? Да и разнообразных прав-то может быть очень много, сколько тогда полей получиться в usergroups? да и вообще, постоянно менять структуру таблицы, как-то "не-айс"… хз…

Dagdamor

Сообщения: 47 Репутация: N Группа: Кто попало

Окт. 14, 2007, 11:31 д.п., спустя 10 часов 49 минут 18 секунд

Timur
Эта таблица нужна в 2 случаях:
1) когда разработчик управляет списком полей профайла в админке, он ведь тоже человек, и желательно ему показывать внятные названия полей, а не просто их имена.
2) при регистрации и редактировании профайла эти дополнительные данные тоже нужны, для отображения формы.
Насчет "постоянного изменения структуры таблицы" здесь уже говорили. Если страшно - не айс. Если не страшно - айс.

TRIAL

Сообщения: 988 Репутация: N Группа: Джедаи

Окт. 15, 2007, 9:42 д.п., спустя 22 часа 10 минут 56 секунд

Я обычно для пользователя делаю отдельное поле в табличке, что-то типа Access и в него заношу все id разделов, к которым у данного пользователя есть доступ. Разделяю эти id каким-нибудь символ и потом при извлечении с помощью explode() создаю массив. Далее при рисовании меню в цикле просто делаю проверку, если в массиве есть данный id или стоит полный доступ то вывожу данные.
Впринцыпе не самый грамотный способ но меня устраивает. Для небольших групп с небольшим кол-вом разделов очень удобно.

from TRIAL with LOVE

Timur

Сообщения: 1068 Репутация: N Группа: Джедаи

Окт. 15, 2007, 2:45 п.п., спустя 5 часов 3 минуты 9 секунд

для меня обычно проблемой является вопрос - что считать привилегией? Доступ к определённому объекту? Но ведь доступ может быть разный:

доступ для просмотра и/или изменения и/или удаления

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

доступ к отдельным записям (каждый модер относиться лишь к определённым разделам, каждый модер может менять данные профили всех участников, если они не модеры и не админы и т.д.)

Я обычно тупо беру за "единицу" модуль (раздел). Тут 2 варианта - есть доступ или нет. Если честно мне самому этот вариант не очень нравиться, т.к. нет "гибкости". Как лучше организовать, я хз…

vasa_c

Сообщения: 3131 Репутация: N Группа: в ухо

Окт. 15, 2007, 3:07 п.п., спустя 21 минуту 14 секунд

Привилегия — возможность выполнить какие-либо действия, которые могут не все.

Система привилегий

Войти