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

Ох, как много текста  Они не могли все более кратко сформулировать? 

Я на деле представляю себе такую систему.

Есть таблица:
ИД группы|ИД пользователя|привелегия
1||create_user
1||edit_user
2||edit_my_profil

Сюда заносятся только разрешенные действия для группы или юзера. Всё, что не разрешено - запрещено.

И есть функция для проверки:


Предлагаю так делать.

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

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

Wowa, 
Такой системой как ты предложил сложно сделать группы пользователей, а если пользователей в двух группах? трех? Там по ссылке есть хороший пример:

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

Opik, все свежие системты управления доступом основываються на ролях и уникальных привилегиях с точностью до одного пользователя. Я разработал(дорабатываю) похожую систему, но есть отличия (с начала):

• есть права(привилегии), организованные в иерархию (дерево, по имени через ".")
• есть гранты, т.е. выдача права с возможным лимитом по календарю, списку IP и другим фильтрам. Гранты бывают двух типов: "добавить" и "удалить". Дают или запрещают право.
• есть пользователи, не важно как авторизуються, но каждый запрос всегда связан с ID текущего пользователя, прямо как в осях какждый процес связан с пользователем.
• есть роли, роль нужна для обьеденения прав в некое логическе целое
• пользователи могут иметь множество ролей, он наследует все права выданные на роль. владение ролями не упорядочено, запрещающий грант права всегда имеет приоритет
• гранты можно выдавать как пользователям, так и группам, личные гранты пользователя имеют приоритет
• наследование и вычисление эффективных такое же как и по ссылке выше.

Это основа, далее конкретный модуль может проверить:

• владеет ли пользоваль правом - простейшая проверка boolean PermissionManager::hasPermission("some.privilege");
• владеет ли пользователь правом и выполняеться ли условие - условие строиться модулем. Модулю предоставляеться ID пользователя, ID права.

Таким образом модуль для работы с юзерами и правами (да, фактически это модуль и его можно убрать физически отключив этот функционал, постовляеться вместе с основой) собирает всех пользователей в группы/контейнерый, при этом группы не имеют иерархии. Один юзер может находиться в нескольких группах, груп может быть сколько угодно. Пользователю можно выдать право на выполнение конкретного действия над пользователями в другой группе. Таким образом можно собрать людей в "топлы" и назначить им одного или более админов с точно разрешёнными действиями над этими юзерами.

Модуль создаёт проверку: конкретное_право + конкретные_группы, где: 

• конкретное_право - владеет ли текущий пользователй этим правом
• конкретные_группы - входит ли список редактируемых пользователей в группы, на которых распространяеться право для текущего пользовате (администратор).

Как видм костяк расширяеться новыми связями по задаче. Естественно что такая гибкость означает тяжёлые запросы и возможно массу инфы доставаемой из БД. Естественно что при каждом запросе БД не трогаеться, для этого система контроля доступа плотно связана с кешированием (не удаляемый (только руками) модуль). При логине человек может подождать 1-5 секунд пока его инфа вся разберёться, затем в его персональный кешь/сессию сбрасываеться эта инфа в виде var_dump файлов и SQLite таблиц.

Модули имеют почтовые ящики, куда другие модули могут посылать уведомления. Система контроля правами проверяет при каждом запросе изменились ли права, если надо, перестраивет кеш. Валидность по календарю, ИП и прочему естественно проверяеться из кеша. Отсюда приемлемая скорость работы.

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

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

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

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

Opik, пиши спецификаицю системы, как будет работать и т.п., структура таблиц, логика работы системы прав. 
Если будут вопросы по ядру, обращайся ко мне - я все объясню. В принципе ядро у нас будет масштабируемое и гибкое, так что проблем с внедрением быть не должно.



Я думаю можно реализовать некие плагины под это дело. А то и вовсе авторизовывать через SOAP сервис какой.

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