Как-то неотвратимо и неторопясь пришла необходимось переписать систему авторизации. Вот какие мысли в голове забродили... Пока на уровне мыслей, до кода не очень далеко, но его пока нет ;-)

Авторизация
Список решаемых задач
Система авторизации предназначена для 
•    разграничения доступа к контенту по логину-паролю.
•    Обеспечения поддержки/запрета множественного(с разных компьютеров) входа одного пользователя.
•    Выяснение количества пользователей в online.
•    наследование прав пользователей по группам и индивидуально
Структура mySql таблицы для поддержки системы авторизации
-

В рамках этой таблицы формируются записи о пользователях и группах. Для каждого пользователя/группы заводится идентификатор и несколько записей со свойствами пользователя/группы. Список параметров (name) фиксирован в рамках одного проекта, но может быть расширен на любые требуемые рамки. Значения ival, tval, sval и dval определяются по смыслу параметра name.

В дальнейшем каждую строчку таблицы вида (ID, name) будем называть параметром `name` пользователя `ID`.

Возможный список имен параметров:
User – имя пользователя
Group – имя группы. Эти параметры не могут встречаться для одного и того-же ID’а, хотя нужно подумать над этой возможностью. Пока Group служит только контейнером для наследуемых прав

Link - Подключение пользователя к группе ival
Password – пароль пользователя для входа
Right – права пользователя/группы.
cRight – вычисленные права, с соблюдением наследования.

Хранение прав пользователей.
В параметре right хранится 2 ассоциативных массива allow и deny, соответственно с разрешениями и запрещениями для данного ID.
Алгоритм идентификации
Для входящей пары логин-пароль производится поиск в базе всех параметров user со значением «логин» и паролем.
Примерный запрос


Вход в систему оформляется вставкой параметра
ID,’Online’, sval=SessionId–соответствующая сессия. Dval-дата входа систему, tval – сопроводительная информация. (REMOTE_IP, X-FORVARDED_FOR, ets…)
Подтверждение входа.
Идентификатор пользователя сохраняется в сессии. При повторном визите зарегистрированного пользователя производится сравнение значения ID-сессии в параметре online пользователя и, возможно, сравнение сопроводительной информации.
При несовпадении пользователь считается незарегистрированным.
Выяснение количества пользователей в online
После входа, для пользователя заводится параметр online с датой входа. Количество пользователей в online – количество соответствующих параметров в базе, имеющих дату не позднее, чем 10 минут назад.
Наследование прав пользователей по группам и индивидуально
Права пользователя находятся в параметре cRight. В случае, если параметр не установлен - выполняется перевычисление прав. В случае, если пользователь наследует только одному ID, права берутся непосредственно оттуда. Если схема наследования сложнее – права пере вычисляются и сохранятся в параметре cRight 

Перевычисление прав
После установки индивидуальных прав для какого либо ID должны быть перевычислены соответствующие ему cRight.
Используется рекурсивный алгоритм: начиная с ID очищаем все права, зависимые от него (id?,‘link’ ,ival =ID)=>delete(id?,’cRight’). Для каждого найденного id? Очистка повторяется.
Предлагаемая ниже схема работает для случая ненаследуемых друг от друга групп.

После входа пользователя в систему производится поиск параметра right для этого пользователя. Затем выполняется поиск параметров link и соответствующих cRight для линкованных сущностей. Права сущностей объединяются обычным OR’ом. После чего права склеиваются с индивидуальными правами.

Переустановленные индивидуальные права сохраняются в параметре right. После установки прав необходимо перевычислить права и поместить композитные права в параметр cRight. После этого необходимо удалить все зависимые (id?,’link’,ival=ID) от этого ID cRight, что вызовет перевычисление их при необходимости.

Дополнительные неожиданные возможности
В предлагаемой схеме можно отображать к примеру,
•    Пользователя с несколькими именами для входа
•    Пользователя с несколькими паролями
•    Неограниченное количество параметров для пользователя.


Это сообщение отредактировал(а) ksnk - 8.5.2008, 12:36

ksnk, 
Не понял, ты хочешь хранить список коннектов и права пользователей в одной таблице?

Добавлено через 3 минуты и 30 секунд
Я бы сделал как минимум две.
Таблица подключений пользователей/групп (вот тут ты хранишь ид текущей сессии, вычисленные права и т.д.)
Таблица пользователей/групп.

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

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

Дык! Лозунг "все в одном" живет и побеждает. Просто таблица коннектов получилась примерно такой-же структуры, так что мне захотелось их объединить... разве что с точки зрения безопасности (таблица на диске сточится и покрошится с большей вероятностью ;-) ) можно бы их разнести, да и оптимизровать ее придется почаще, ... но пока - не хочу...

Дык! За это в основном и велась борьба. Хотелось полное наследование от вложеных "деревянно" друг в друга групп...

У меня какое-то внутреннее предубеждение насчет хранения динамических/временных данных и справочников в одной таблице.

Таблица прав это справочник. А ты фактически при каждом коннекте будешь его дергать запросом на обновление.

С другой стороны таблица активных коннектов - это по-сути временная таблица.

Вот кстати и причина сделать ее отдельно. Число пользователей может быть достаточно большим. А активных коннектов - все же меньше.
Поэтому для активных подключений можно выбрать другой тип таблицы (Memory) например.


И еще, поясни вот эту цитату. На пальцах, если можно. У группы есть разрешение на редактирование, а у конкретного пользователя принадлежащего этой группе стоит запрет на редактирование.
Какое право он получит в твоем варианте?

Мне кажется стоит пользоваться И, вместо ИЛИ. Т.е. все что не разрешено - запрещено.

Ну, как я пока себе представляю - права юзера - два ассоциативных массива allow и deny. Выглядят они, с точки зрения пользования, как-нибудь так:


Скомпилированные права - объединение всех непересекающихся полей в массивах. Пересекающиеся поля одного уровня (первые "группы-предки" цепочки наследования) объединяются простым OR'ом. Сливать собственные поля с наследуемыми нужно более экзотично... У меня пока вот так

Хотя до проверки всего этого добра я не добрался ;-)

Это сообщение отредактировал(а) ksnk - 8.5.2008, 15:53

ок, спасибо