ФорумПрограммированиеPHP для идиотов → Система привилегий

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

  • vasa_c

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

    Spritz 13 октября 2007 г. 11:34

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

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

    Spritz 13 октября 2007 г. 13:24, спустя 1 час 49 минут 22 секунды

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

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

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

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

    Spritz 13 октября 2007 г. 16: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 Группа: Джедаи

    Spritz 13 октября 2007 г. 16:32, спустя 8 минут 6 секунд

    мой вариант:

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



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

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

    Spritz 13 октября 2007 г. 17: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 Группа: в ухо

    Spritz 13 октября 2007 г. 18:14, спустя 44 минуты 12 секунд

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

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

    Spritz 13 октября 2007 г. 19: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 Группа: в ухо

    Spritz 13 октября 2007 г. 19:13, спустя 4 минуты 35 секунд

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

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

    Spritz 13 октября 2007 г. 19:33, спустя 19 минут 38 секунд

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

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

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

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

    Spritz 13 октября 2007 г. 20:27, спустя 54 минуты 32 секунды

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

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

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

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

    Spritz 14 октября 2007 г. 0:42, спустя 4 часа 14 минут 38 секунд

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

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

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

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

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

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

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

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

    Spritz 15 октября 2007 г. 9:42, спустя 22 часа 10 минут 56 секунд

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

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

    Spritz 15 октября 2007 г. 14:45, спустя 5 часов 3 минуты 9 секунд

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


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


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


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



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

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

    Spritz 15 октября 2007 г. 15:07, спустя 21 минуту 14 секунд

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

Пожалуйста, авторизуйтесь, чтобы написать комментарий!