Структура таблиц при разграничение прав доступа: пользователи, группы, права, объекты

[Гриша К.]

Структура таблиц при разграничение прав доступа: пользователи, группы, права, объекты

Здравствуйте.
Есть задача сделать возможность управления разграничением прав доступа пользователей на сайте:
пользователям назначаются права (просмотр, добавление, редактирование, удаление)
на объекты (каталог товаров -> добавление, редактирование),
пользователи группируются в группы (администраторы, партнеры, пользователи).

Перед этим попробовал phpGACL http://php.russofile.ru/ru/translate/rights/phpgacl/, очень большой модуль, много возможностей, и решил попробовать сделать что-то по проще, потому что все что мне надо, это те права и группы, которые описаны выше. Я также думаю, что данный модуль добавит дополнительную нагрузку на сайт, и если его использовать, необходимо будет синхронизировать таблицу пользователей, либо добовлять пользователей в модуль в ручную, вот это мне не нравится.

В соответствии с этой статьей http://www.citforum.ru/programming/digest/access.shtml, решил сделать похожую структуру БД, но проблема в том, что нужно сделать так, чтобы пользователю можно было назначать или отменять персональные права доступа, возможно вы используете похожие схемы и могли бы подсказать какой-то вариант решения?

Вот пример запроса к БД, с указанием структуры:

SELECT *
FROM 
	users,		 #user_id, user_name
	groups,		#group_id, group_name
	rights,		#right_id, right_name
	objects,	   #object_id, object_name
	user_group,	#user_id, group_id
	user_right,	#user_id, right_id, object_id
	group_right	#group_id, right_id, object_id
WHERE
	users.user_id = user_group.user_id AND
	groups.group_id = user_group.group_id AND

	users.user_id = user_right.user_id AND
	rights.right_id = user_right.right_id AND

	groups.group_id = group_right.group_id AND
	rights.right_id = group_right.right_id AND	

	objects.object_id = user_right.object_id AND
	objects.object_id = group_right.object_id

 

[Кром]

Очень красиво все написано и оформлено, прямо реферат. Непонятно одно, в чем суть проблемы?

 

[Гриша К.]

Кром, вопрос выделил зеленым и приведу еще раз:

проблема в том, что нужно сделать так, чтобы пользователю можно было назначать или отменять персональные права доступа, возможно вы используете похожие схемы и могли бы подсказать какой-то вариант решения?

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

 

[Кром]

Это все понятно. Непонятно в чем именно у тебя проблема.
Ты не знаешь, как сделать связь между таблицей пользователей и таблицей объектов? Или не знаешь какую связь выбрать, один ко многим или многие ко многими? Или не знаешь, какой формат должен быть у таблицы с пользовательскими правами?

 

[flash-vkv]

решить вашу проблему не могу, но сам делаю след.. образом.
у меня одно поле(колонка) в таблице содержит группу обьектов (обьект это мин. еденица), при запросе данных, предварительно определяю все доступные обьекты, а потом подставляю их в SQL запрос, примерно так : table.right IN (3, 14, 54, ... , 8 )
доступные обьекты "3, 14, 54, ... , 8" я сохраняю в виде кэша, что сушественно сказывается на скорось.
модуль(класс) который формирует доступные обькты делал свой, но правда получилось похоже на phpGACL. Средство хранения прав я использую XML и это не сказывается на производительнось (потому как кэш).
назначать индивидуально каждому пользователю права(возможности ) я не стал, просто если для него выделить отдельную группу, какраз и получаю индивидуальность.

 

[Гриша К.]

В приведенной выше структуре БД, получается, так, что в итоге выводятся те права для пользователя, которые есть и у пользователя (user_right) и у группы в которую он входит(group_right). В данном случае я могу уменьшать права у пользователя в группе, но немогу их делать больше чем есть у группы.
Я незнаю какой должна быть структура БД, чтобы у пользователю в группе можно было делать исключение, увеличив набор прав.
Я думал использовать левосторонне объединение, но это у меня не получаетя, слождная структура.

 

[Кром]

>В данном случае я могу уменьшать права у пользователя в группе, но немогу их делать больше чем есть у группы.

Ты можешь сделать еще один запрос к дополнительной таблице, где можно хранить любые исключения.

 

[flash-vkv]

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

к примеру право на просмотр имеим обьекты IN (3, 14, 54, ... , 8 )
право на удаление обьекты IN (3, 14 )
еше какое-то право IN (3, ... )

 

[Гриша К.]

Кром, спасибо за ответ.

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

flash-vkv, спасибо за ответы.
Если у меня не получится найти решения, чтобы были исключения для отдельных пользователей в группе, то конечно придется делать дополнительные группы, но очень удобно когда пользователю в группе можно дать отдельные права, из одного пользователя создавать группу тоже нет смысла.

Вы написали про кэширование, я как раз думал о том, как неделать запрросы к БД постоянно при проверке полномочий. Сам кэширование никогда не использовал, я щас нашел класс Pear::Cache Lite, запрос закэшировать получилось, правда непойму на какое врем надо кэшировать запрос, как вы делаете?

 

[flash-vkv]

дело в том что я не использую phpGACL а сделал свой аналог, также как и phpGACL я использую древа, древо обьектов древо полномочий и древо возможностей(в phpGACL если я там все правельно понял их два). как вы понемаете изменения в одном из древ приведет изменению всей структуры. Потому я не вижу смысла пытаться сохранить весь кэш, я его просто удаляю и он наченае занова формироваться по ходу запросов. Конечно можно продумать алгоритм сохранения некоторых данных но это громозко и на это нужно время.
я писал выше что использую XML , но сейчас думаю использовать древа в SQL, возможно что перенеся на SQL данные, вообше пропаден необходимость в попытках сохранения некоторых частей кэша.
сама структура кэша легко понять, "3, 14, 54, ... , 8 ", формирую эту строку след . образом. сделал функцию GetOpenObjs(obj) она просматривает все дочернии узлы "obj" и те которые подподают под палитеку добавляю к строчке "3, 14, 54, ... , 8 ". а таблица кэша это три колонки obj | right | open_obj , простым SQL я легко извлекаю нужный мне кэш.

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

 

[Гриша К.]

flash-vkv, спасибо большое за ваши разъяснения.

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