Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Vingrad CMS > Система прав

Автор: Opik 3.9.2006, 01:13

Читать тут: http://popoff.donetsk.ua/text/work/libs/passport/privilege/admin.html

Автор: Wowa 3.9.2006, 01:51

Ох, как много текста  Они не могли все более кратко сформулировать?  Я на деле представляю себе такую систему. Есть таблица: ИД группы|ИД пользователя|привелегия 1||create_user 1||edit_user 2||edit_my_profil Сюда заносятся только разрешенные действия для группы или юзера. Всё, что не разрешено - запрещено. И есть функция для проверки: Код // Проверяем есть-ли права для вызова определенной функции function have_permission($permission, $action='') {     $sql = "SELECT * FROM $table_permissions WHERE id='{$_SESSION['idmgroup']}' AND permission='$permission'";     $have_permission=db_row($sql);     if ($have_permission['id']) {return 1;} else {         switch ($action) {             case 'return':                         return;                          break;             default:                        $authorization_class->access_denied();         }     } } Предлагаю так делать.

Автор: Opik 3.9.2006, 02:01

Wowa,  Ты как нить почитай, очень гибкая система. ИМХО Это стоит прочесть :)

Автор: Wowa 3.9.2006, 02:03

Opik, а чем моя не гибкая?  Ответь, тогда прочту

Автор: Opik 3.9.2006, 02:03

Wowa,  Такой системой как ты предложил сложно сделать группы пользователей, а если пользователей в двух группах? трех? Там по ссылке есть хороший пример: Цитата В небольших или простых по устройству системах используются простые способы управления привилегиями. Например, в системе дистанционного образования Moodle все пользователи делятся на группы: администраторы, создатели курсов, преподаватели, студенты и гости. В зависимости от того, какой группе принадлежит пользователь, у него есть разные привилегии.  Но уже даже в этой системе мы можем наблюдать, что не все так просто с этими группами. Например, создатели курсов считаются преподавателями только в пределах тех курсов, которые они сами создали, а при просмотре других курсов они считаются студентами. Мы не можем для каждого конкретного преподавателя указать, может ли он добавлять в свой курс других преподавателей или же это может сделать только создатель курса. Для облегчения поиска нужных курсов эти курсы распределены по категориям (по папками), которые имеют иерархическую организацию. Если мы записываем человека в группу создателей курсов, то он может создавать курс в любой категории - мы не можем ограничить, внутри каких категорий он может создавать новые курсы. Создав новый курс, мы не можем записать на него сразу всю группу студентов, мы должны добавлять студентов по одному, выбирая их из !ВСЕХ! пользователей, зарегистрированных на сайте. Либо мы можем сообщить им кодовое слово, и тогда они сами себя добавят - но где гарантия, что это кодовое слово не станет известно посторонним? Есть также много других ограничений.

Автор: Wowa 3.9.2006, 02:19

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

Автор: Sardar 3.9.2006, 04:40

Opik, все свежие системты управления доступом основываються на ролях и уникальных привилегиях с точностью до одного пользователя. Я разработал(дорабатываю) похожую систему, но есть отличия (с начала): есть права(привилегии), организованные в иерархию (дерево, по имени через ".") есть гранты, т.е. выдача права с возможным лимитом по календарю, списку IP и другим фильтрам. Гранты бывают двух типов: "добавить" и "удалить". Дают или запрещают право. есть пользователи, не важно как авторизуються, но каждый запрос всегда связан с ID текущего пользователя, прямо как в осях какждый процес связан с пользователем. есть роли, роль нужна для обьеденения прав в некое логическе целое пользователи могут иметь множество ролей, он наследует все права выданные на роль. владение ролями не упорядочено, запрещающий грант права всегда имеет приоритет гранты можно выдавать как пользователям, так и группам, личные гранты пользователя имеют приоритет наследование и вычисление эффективных такое же как и по ссылке выше. Это основа, далее конкретный модуль может проверить: владеет ли пользоваль правом - простейшая проверка boolean PermissionManager::hasPermission("some.privilege"); владеет ли пользователь правом и выполняеться ли условие - условие строиться модулем. Модулю предоставляеться ID пользователя, ID права. Таким образом модуль для работы с юзерами и правами (да, фактически это модуль и его можно убрать физически отключив этот функционал, постовляеться вместе с основой) собирает всех пользователей в группы/контейнерый, при этом группы не имеют иерархии. Один юзер может находиться в нескольких группах, груп может быть сколько угодно. Пользователю можно выдать право на выполнение конкретного действия над пользователями в другой группе. Таким образом можно собрать людей в "топлы" и назначить им одного или более админов с точно разрешёнными действиями над этими юзерами. Модуль создаёт проверку: конкретное_право + конкретные_группы, где:  конкретное_право - владеет ли текущий пользователй этим правом конкретные_группы - входит ли список редактируемых пользователей в группы, на которых распространяеться право для текущего пользовате (администратор). Как видм костяк расширяеться новыми связями по задаче. Естественно что такая гибкость означает тяжёлые запросы и возможно массу инфы доставаемой из БД. Естественно что при каждом запросе БД не трогаеться, для этого система контроля доступа плотно связана с кешированием (не удаляемый (только руками) модуль). При логине человек может подождать 1-5 секунд пока его инфа вся разберёться, затем в его персональный кешь/сессию сбрасываеться эта инфа в виде var_dump файлов и SQLite таблиц. Модули имеют почтовые ящики, куда другие модули могут посылать уведомления. Система контроля правами проверяет при каждом запросе изменились ли права, если надо, перестраивет кеш. Валидность по календарю, ИП и прочему естественно проверяеться из кеша. Отсюда приемлемая скорость работы.

Автор: Opik 3.9.2006, 14:57

Wowa,  Перефразирую твой вопрос: "Действительно ли нам нужна гибкая система?". Мое ИМХО - нужна. Sardar  лишь это подтвердил

Автор: Wowa 3.9.2006, 15:01

Opik, сколько времени у тебя уйдет на ее реализацию?

Автор: Opik 3.9.2006, 15:25

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

Автор: Wowa 1.10.2006, 19:44

Кстати, предлагаю сделать возможным подключать базы юзеров сторонних движок для прохождение авторизации. Например так, чтобы пользователи форума Invision могли залогиниться на сайте с Vingrad CMS. (естественно при этом должен быть обеспечен доступ к таблице ibf_users). На мой взгляд это довольно легко реализовать, но польза будет колоссальная.

Автор: IZ@TOP 4.10.2006, 09:26

Opik, пиши спецификаицю системы, как будет работать и т.п., структура таблиц, логика работы системы прав.  Если будут вопросы по ядру, обращайся ко мне - я все объясню. В принципе ядро у нас будет масштабируемое и гибкое, так что проблем с внедрением быть не должно. Цитата(Wowa @  1.10.2006,  20:44 ) Кстати, предлагаю сделать возможным подключать базы юзеров сторонних движок для прохождение авторизации. Например так, чтобы пользователи форума Invision могли залогиниться на сайте с Vingrad CMS. (естественно при этом должен быть обеспечен доступ к таблице ibf_users). На мой взгляд это довольно легко реализовать, но польза будет колоссальная.  Я думаю можно реализовать некие плагины под это дело. А то и вовсе авторизовывать через SOAP сервис какой.

Автор: Wowa 22.10.2006, 15:34

Опик с сегодняшнего дня в отпуске 41 день. Поэтому системой прав придеться заняться мне.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)