система прав доступа

[desperado]

система прав доступа

структура таблиц::

users:|user_id|user_login|user_pass
groups:|group_id|group_name
users_to_groups:|id|user_id|groupt_id

modules:|modules_id|modules_name

actions:|action_id|modules_id|action_name
users_to_actions:|id|user_id|action_id
groups_to_actions:|id|group_id|action_id

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

а вот задачка по интересней:
раздавать права на уровне "объектов". т.е. когда "новость" это "объект" к которой привязаны "действия" (скажем: удалить \ изменить \ публиковать \ снять с публикации...).

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

к примеру:

object:|object_id|object_name|
       |1        |новость 1  |
       |2        |новость 2  |

actions:|action_id|action_name     |
        |1        |удалить         |
        |2        |редактировать   |
        |3        |опубликовать    |
        |4        |снять публикацию|

objects_to_actions:|id|object_id|action_id|
                   |1 |1        |1        |
                   |2 |1        |2        |
                   |3 |1        |3        |
                   |4 |1        |4        |
                   |5 |2        |1        |
                   |6 |2        |2        |
                   |7 |2        |3        |
                   |8 |2        |4        |

но тут возникает вопрос - как связывать пользователей\группы с правами на действия от объекта, на ум приходит только одно решение - связывть пользователей и группы с идентификатором в таблице objects_to_actions, но что-то меня терзают смутные сомнения, что это не есть гуд.

у кого какие мнения на сей счет?

 

[crocodile2u]

Может быть, использовать *nix'овую систему? rwxr-xr-x ?

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

 

[Stm]

может так
objects_to_actions:|object_id|action_id|user_id

 

[desperado]

2crocodile2u
да, но тогда это нас заганяет в узкие рамки и ограничивает заранее заложенными действиями\операциями, что не есть гуд %\

 

[Stm]

[...]

 

[desperado]

2 Stm:
было адресовано crocodile2u, только пока писалось - твое появилось

-~{}~ 15.06.04 17:05:

надо еще добавить только:

object_groups_to_action:|group_id|object_id|action_id|

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

 

[slach]

десперадо кешировать праваа ЛЕГКО достаточно

для этого можно просто вытащить все права для всех групп... к которым относится текущий юзер... ко всем объектам (разделам сайта) ... в массив

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

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

заодно в системе можно завести понятие Security Context Cache period

 

[desperado]

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

конфликтов тут вообще нет - оно либо разрешено (о чем записано) либо нет (о чем не сказано вообще).

 

[Stm]

может быть, имеет смысл разграничить права не на уровне юзеров, а на уровне групп, плюс хранить для каждого объекта owner, тогда в принципе можно ограничиться правам на группу объектов, по-моему, разумный компромисс, не active directory же на php писать.

 

[desperado]

2 Stm
обрезать до групп, свести к группе объектов (модулю, части модуля) и испаганить все до безобразия введением для модуля отдельной таблицы с кучами столбцов и вышивать в них крестики да нолики супротив id-группы.

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

 

[Stm]

может я не совсем ясно выразился, ну на примере этого форума, автор сообщения имеет право его редактировать, замечу, что в этом отношении все сообщения равноправны, то есть объект owner имеет права редактировать любой объект класса "сообщение" (для которого он owner), другое дело, что owner у каждого сообщения свой, таким образом, достаточно определить права только для класса объектов, а не для каждого в отдельности, а стоить это будет только проверки является ли юзер владельцем объекта.

 

[desperado]

или модератором данного форума, т.е. группы топиков (объектов) или админом всей доски, т.е. совокупности группы форумов. (%

надо будет ночью поразмыслить.

 

[xRay]

desperado
Посмотри вот вроде то что тебе может подойти, или просто идею посмотриш.
http://phpgacl.sourceforge.net/

 

[MagicGTS]

Я нечто подобное уже делаю (только это предназначено для софт портала, да не суть важно). Я взял за про образы систему атрибутов как Win* так *nix систем. И решил так: Есть пользователи и есть группы. И первые и вторые обладают атрибутами для доступа к некоторому объекту (файл, каталог и etc). Если у объекта есть права для пользователя, то все права для групп, в которые входит ползователь игнорируются (считаеться что на данный объект права даны эксклюзивно). Если прав для юзера нет, то смотряться права для групп в которые входит юзер, результирующие права будут суммой всех прав для соответствующих групп. Если для объекта вообще нет прав, то производиться поиск прав для родительского объекта, и так вплоть до корня. А если и у корня нет нужных прав, то аксесс денайд анд ерорр.

 

[desperado]

мысли в слух

-+система_новости
 |
 +-+раздел-1
 | |
 | +-новость-1
 | +-новость-2
 |
 +-+раздел-2
   |
   +-новость-3
   +-новость-4

т.е. у новость-1 и новость-2 родитель - раздел-1, у новость-3 и новость-4 - раздел-2. для раздел-1 и раздел-2 родитель это система новостей. в итоге для новость-* нам достаточно хранить владельца, а права прописывать для группы\пользователя у разделов и\или всей системы_новостей. тогда еще для полной картины надо будет добавить псевдо-группу - владелец.

итого получаем:

object:|object_id|object_parent|object_owner|object_name|

права на которые определяем через эту табличку.
object_groups_to_action:|group_id|object_id|action_id|

xRay
сенкс за ссылку - изучаю.

 

[nightik]

Соглашусь с предыдущим оратором. Это ест классическая схема списков прав доступа, за одним лишь НО. Помимо "разрешения" в классической схеме рассматривается и "запрещение". т.о. сехма преобретает следующий вид.
Если для объекта есть список прав для определённого пользователя и в них есть "запрещение" на запрашиваемое действие, то "акцесс денайд", если есть разрешение, то считается доступ эксклюзивным. Если прав для конктретного пользователя нет, то рассматриваются права доступа для групп членом которых является пользователь и так же: если есть "запрещение" - денайд, разрешение сакцесс

Вообщем идея такая

 

[desperado]

я рассматриваю по умолчанию - все запрещено, а вот то что надо - разрешать.

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

 

[GSL]

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

Интересно, а что если заменить схему на хранение прав
user_id:|group_id:|app_permission[32] bit|sys_permission[32] bit

т.е. 32 флага на доступ к системным операциям администрирования и 32 флага на доступ к апликативным операциям. И думается мне, что вряд ли реально сможете придумать такой объект в реальной системе у которого будет более 32 возможных акций связанных лично с его функциональностью, а системных, с изменениями прав доступа и всякими другими системными операциями я придумал только 20, и то 10 притянуты за уши. кстати никто не мешает ввести
addition_permision 32bit.

По сути что дает нам такая схема. 1 записть в базе говрит нам о том что у пользователя в данной группе за права, названия и иерархия групп храниться в отдельной таблице, причем хранени дерева групп делается только для видимой совместимости с общепринятыми системами, пока никакой функциональноти на себе не несет.

далее....

При старте системы мы чиаем все эти записи из такой таблицы, и получаем весь список прав пользователя во все системе.....

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

Если кому интересно можем продолжить, я сам еще не до конца оформил в голове всю схему, так что можно обсудить это все....

 

[desperado]

сразу нет и причина в следующем:

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

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

 

[GSL]

desperado просто наверное не совсем правильно выразился...
Ок добавили новый модуль о котором не знает ядро....
Но модуль знает о ядре ? Или нет ?

Ядро все равно не может редактировать неизветный объект.
Теперь так Если модуль неизвестный, то получается забавная вещь, либо нужны колбеки на изветные заранее определеннве акции, т.е. поулчается что вы заранее ограничиваетете модуль по его функциональности. ( удалить, добавить, редактировать, перенести, заблокировать ) и тогда вы контролируете все.... написание модуля стандартизовано как наследование абстрактного класса. Я такое видел уже, каждый параметр описан как объект начального уровня(int, string, bool, text, memo, html_memo etc.), и потом из них строятся те объекты о которых говорится.... Но это только лента новостей с линейным постоением, как только попробуете написать что-то древовидное с циклическими связями...... все равно напишите свой модуль

теперь пожалуй вернусь попробую упростить задачу ядро само ничего не делает.... хотя бы потому что контролировать все бессмыслено, как только вы включите мой модуль я первым же прямым запростов в базу попорчу там все что захочу, потому как все что тут делается это эмуляция бурной деятельности распределения прав, в MS-DOS системе, т.е. Реально пользователь только один и он сам себе запрещает и разрешает.... и запретить ему куда либо лазить нпрямую все равно нельзя... т.е. если пользователь для вашей системы сможет запустить phpMyAdmin с теми же правами доступа к базе что и скрипт, хана вашей базе, или придеться очень упорно делить все на уровне этой базы и чуть ли не для каждой акции логиниться с разными параметрами.... Вообщем надеюсь понятно.....

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

теперь самое интересное. sys_permission оставим в покое, это права на изменение прав. а том что именно содержиться в объекте знает только модуль, так пусть с правами на его изменения тоже работает только модуль app_permission/ Я пересмотрет хигову тучу CMS и ни один так и не смог сделать своими свойствами ядра что-нить сложнее ленты навостей, т.е. первый же поиск в базе, с операциями над данными, ведет к созданию нового модудя, который соответственно это и умеет делать и готовить инфу для темплейта. Вообщем я тут целую статью могу написть из того что не может ни один CMS на уровне ядра....

Так может тогда и не надо такого безпомощного ядра ?
По мне ядро это набор струтурных стандартизованных данных и функций, которые помогут мне с минимальными затратами писать модули....Вообщем буду следить за такими темами, может я чего просто не понимаю...