А давайте-ка поговорим о наиболее оптимальном варианте системы авторизации / разграничения прав на сайте (в теоретическом плане, т.е. алгоритм, примеры кода можете оставить при себе )?

Думал об этом недавно и решил вот узнать, что думают по этому поводу другие.

Итак, мы имеем сайт, который состоит из модулей (новости, контент, файловый архив). Так же мы имеем 4 основных группы пользователей - забаненые, гости, пользователи, администаторы + доп. группы (напр. "Клиенты", "Support", etc). На сайте находится n-ое количество страниц, генерируемых модулями и i-ое количество зарегистрированных пользователей. Задача - связать это все в одну систему разграничения прав, которая зашивается в ядро CMS (ибо модулем это будет выглядеть как-то не так).

Как решить задачку-то?

1. Каждая группа имеет свои права (забаненые - самые низкие, администраторы - самые высокие, остальные - промежуточные значения).
2. Каждый пользователь принадлежит к какой либо группе (забаненный, гость, пользователь, администратор или др.).
3. Каждый пользователь имеет свои уникальные права, если они не заданы или менее приоритетные чем у группы, используются права группы.
4. Каждый модуль сайта имеет свой уровень доступа, т.е. страницы модуля могут просматривать только пользователи групп с соответствующими правами. Плюс ко всему каждая страница имеет свой уровень доступа, если же он не задан - используется уровень доступа модуля, которым она генерируется.

Все вроде бы неплохо получается, только вот у меня не получается продумать связь прав пользователей с уровнями доступа модулей. При каких значениях модуль доступен пользователю, при каких нет. Можно прописать цифрами (0 - ничего, 1 - просмотр, 2 - просмотр и редактирование) уровни доступа для каждой группы, но ведь количество групп постоянно меняется. В общем, тут я совсем запутался и кроме как сделать уровни доступа а-ля 0, 10, 20, 30 ничего не придумал (страница имеет уровень доступа, если права >= уровню, то просмотр возможен). Здесь и хочется выслушать ваши мысли 

В общем, нужны идеи по организации базы данных. Получается, что у нас имеются таблицы: members (id, gid, name, privileges), groups(id, name, privileges), modules(name, privileges).

Go мысли вслух 

Права лучше идентифицировать по кодам. "news:write", "article:delete" и т.п. Соответсвенно, базовые права для модулей: добавление, редактирование и удаление - создаются автоматически при добавлении модуля. Так же они присваиваются главному админу. А он их потом раздает всем кому надо, т.е. как группам так и отдельным пользователям.

write, delete - это просто слова или это хранится по айдишникам в отдельной таблице ?*

Да я думаю это не важно, просто как я понял, нужно хранить права в строке, где будет нечто "news=2|content=1" и т.д. Строка парсится и уже через if-else выруливается все.

Еще какие предложения будут?

Неплохо бы, чтобы пользователь мог входить в несколько групп сразу.

imho, права - отдельный объект, однако для определенности можно именовать его массивом ;-) У каждого юзера-группы свой массив прав. Нужно, правда придумать способ склейки всех 'наследуемых' прав в один массив.
Массивы достаточно удобно сериализовать...

А как-же без кода? ;-)

Каждый модуль/объект/страница - любая сущность имеет список действий которые над ней можно совершить.
чтение/создание/редактирование/удаление.
Отсюда и танцуешь.

Таблица возможных действий для каждого объекта (например, технический лог можно только записывать, прочесть нельзя, какие бы там у кого права не стояли).
Если не установлены он наследует от родителя. Если вообще ничего не стоит, то все возможности доступны.
objects_actions (id, select, insert, update, delete)

Таблица прав групп/пользователей
member_rights (id, select, insert, update, delete, oid)

Для действий по умолчанию в objects - создаешь корневую запись где все разрешено/запрещено (это зависит от идеологии ресурса, я бы выбрал первый вариант).

Для прав по умолчанию в members - создаешь корневую запись, где все действия запрещены/разрешены (это зависит от идеологии ресурса, я бы выбрал первый вариант)

И собственно все.

Да, отдельно может быть таблица объектов.
И отдельно таблица участников (группа - это тоже участник, просто содержащий других участников).
тут все просто
objects, members (id, pid, name, somethingelse). Отличия в структурах допишешь сам, какие тебе нужны.

Когда проверяем права, выбираем, для начала, состояние ВОЗМОЖНЫХ действий над объектом (если их нет для него, берем родительские и т.д. вверх до самого корня), затем состояние прав по-умолчанию, затем групповых прав, и в конце персональных прав.
Над всеми разрешениями производим операцию ЛОГИЧЕСКОЕ И.
Т.е. если запрещено для группы, то, чтобы там не стояло для пользователя - ему запрещено тоже.

Можно усложнить схему, для случая, когда пользователь состоит в разных группах одновременно. Тогда для групп можно расставить ранг/вес. И соответственно браться разрешения будут из группы с наибольшим рангом.

Да уж, давно придумали: логическое "или" называется.  ну и соответственно: нет доступа - 0, чтение - 1, добавление- 2, редактирование/удаление - 4. 

source777, Я там упростил... по уму должно быть right_READ=1 и right_DENY_READ=4... Вот теперь интереснее?

Хм. А чем Zend ACL не катит? 
И вообще, у каждого объекта CMS должен быть ID

awers, не катит ка минимум потому, что является частью фреймверка.

All, в дествительности, все своидтся к общему слчяаю ACL, которая упрощается под текущую задачу. Если взглянуть на задачу топикстартера, то это оно и есть. Ну а дельше... 
1. Посмотреть распределение прав в известных CMS и фреймверках
2. Посмотреть standalone реализации. Например тут

Это сообщение отредактировал(а) solenko - 6.5.2008, 01:58

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

Модуль Articles.
read - чтение элемента
new - создание нового элемента
active/deactive - активация / деактивация (отображение на внешней части сайта)
edit -  редактирование

Нужны 2 таблицы 1-я с группами юзеров, 2-я с самими юзерами.
Права присваиваются группе юзеров.

Как происходит присвоение прав группе.
1. Выбираем набор общих действий галочками RNAE (read [0 или 1], new [0 или 1], active [0 или 1], edit [0 или 1])
2. Выбиаем модули к которым есть доступ у группы.
3. Выбираем доступ к каким-либо уникальным в рамках конкретного модуля действиям (к примеру, очистить статистику, переиндексировать содержимое и т.п.).

Само собой при создании модулей, нужно создавать список действий, которые можно поизвести над модулем.

Всё намного сложнее, но я реализовывал данную схему в ЦМС и она прекрасно работает и справляется со всеми задачами.

Это сообщение отредактировал(а) PHPExpert - 13.5.2008, 13:48

PHPExpert, а как она управляется с правами на уровне еденицы контента? ;)

А в чем разница между группой и юзером? 

> PHPExpert, а как она управляется с правами на уровне еденицы контента? ;) 

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

Вот к примеру, рассмотрим веб-формы для назначения прав доступа определённой группе пользователей:

Права для группы admin модуль articles
--------------------------------------------------------------------
read:1, new:1, edit:1, active:1, delete: 1
далее идёт список всех существующих групп с галочками, если галочка стоит, то данные выше права могут распространиться на выбранные группы
[О] admin
[О] moderator
[О] contenter
[Х] all
--------------------------------------------------------------------
и т.д. для всех модулей системы

Права для группы moderator и модуля articles
--------------------------------------------------------------------
read:1, new:0, edit:1, active:1, delete: 1
[О] admin
[О] moderator
[Х] contenter
[О] all
--------------------------------------------------------------------
и т.д. для всех модулей системы

Права для группы contenter и модуля articles
--------------------------------------------------------------------
read:1, new:1, edit:1, active:0, delete: 1
[О] admin
[О] moderator
[O] contenter
[О] all
Если не выбрана ни одна группа, то всё можно делать только над записями, которые созданы самостоятельно, т.е. под конкретным юзернеймом
+ active по умолчанию 0 (выводить на сайт или нет) и его может поменять только модератор или админ.
--------------------------------------------------------------------
и т.д. для всех модулей системы

В приведённом мною примере, можно всё упростить тем, что сделать общие галочки для сходных действий модулей.
Например, выделить во всех модулях весь read и т.п.

А ещё, нужно не забыть, что в системе могут быть несколько сайтов!!! 

В общем, ещё много много ньюансов с этим, все писать просто нет сил...

> А в чем разница между группой и юзером? smile 
В группе может быть сотня юзеров и нет никакого смысла вязать права конкретному юзеру
(это относится только к моему методу присвоения прав)

PHPExpert, вы меня не поняли. Два простых примера:
1. На этом форуме есть закрытые разделы, доступные только избранным.
2. Я хочу создать фотку, которая будет доступна для просмотра только пользователям, которые записаны ко мне в друзья

По вашей же система пользователь/группа может или смотреть или не смотреть ВСЕ фотки.

Всё понял, прошу прощения. 
Я просто говорю про доступ в админке...