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

[Sad Spirit]

А у кого-нибудь здесь есть опыт реализации модели RBAC?

суть вкратце в следующем. есть таблица Пользователей, есть таблица Ролей, между ними связь M:N. Есть также таблица Прав (подмножество Объект * Действие), у которой связь M:N с таблицей Ролей.

Пользователь имеет Права в соответствии с назначенной Ролью.

 

[GSL]

Sad Spirit Вы наверное телепат.... но я тут уже 3 месяца пытался понять что я придумываю, оказалось все уже давно придумано, RBAС конесно сильно умнее и сложнеее того что я тут рожаю в муках(первое впечатление), но принцип почти тот же.... Попробую почитать, может многое станет яснее.... хотя англицкий у меня очень хреновы....

Вообщем спасибо большое.....

 

[desperado]

не понял? причем тут права ядра и причем тут пользователю доступ в phpMyAdmin? вещи как-то не совместимые.

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

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

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

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

 

[nRay]

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

Идея: Система, хранения юзеров/групп/прав ничего не знает об объектах(новости, статьи) вообще. Она имеет свою структуру, и свой api.

Права:
Новость (key=news)
.....Редактировать (key=edit)
.....Удалить (key=delete)
.....Опубликовать (key=open)
Сообщение (key=message)
.....Свои(key=own)
..........Редактировать (key=edit)
..........Удалить (key=delete)
.....Чужие(key=foreign)
..........Редактировать (key=edit)
..........Удалить (key=delete)

Профили:
имя, связь профиль-права

Пользователи:
имя, пароль, связь пользователь-профиль, связь пользователь-права(опционально)

а далее самое интересное, в любом месте программы:

if (AccessSystem::check_access($user_id, '/news/')) {
}

if (AccessSystem::check_access($user_id, '/news/edit/')) {
}

if (AccessSystem::check_access($user_id, '/message/own/edit/') {
}

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

 

[GSL]

desperado я рассматриваю другую ситуацию...
1. Системы с подобным контролем доступа подразумевает невозможность ее обхода( дыры реализации не рассматриваются ) Иначе грош ей цена, это просто загрузка ресурсов левой и не нужной никому работой.
2. Если все рвно модуль надо чекать на совместимость, иожет просто прекратить пытаться им управлять из ядра, а просто чекать при подключении ?
3. Ядро с определением запроса и имяни модуля это скрипт в 2 switch в самом сложном варианте.
4. Как интересно ядро умеет определить, что за данные дать модулю, кроме параметров, которые дал юзер. Модуль таки просит их сам. Уверяю вас ни один алгоритм не даст вам возможности заранее узнать, что за данные захочет модуль если он сложнее ленты навостей, да и то частный случай, на основе которого строят CMS.
5. Вы идете здесь на страшный компромис. Говоря, что вообщем-то инфа недоступна всем подряд, ее даст ядро. С одной стороны готов согласиться, что если модуль пользуется только API ядра для запроса данных из базы и их созранения, то вы обеспечите эту самую безопасность... но тут вы резко и 100% отрежите яйца нормальному общению с базой с точки зрения скорости и построения SQL запроса.
6. Я всегда удивлялся, почему CMS/PHP такик страшно тормознутые, но после тога как начал читать и пробовать писать мелкие примеры, понял... основы для этого две. Первая - лень оптимизировать решения других систем, и слепое копирование методологии. Вторая желание создателей почуствовать себя большими, т.е. написать Windows/*nix на php. Это не оскарбление, это просто непонимание зачем забивать шурупы кувалдой.
7.Вообщем мне так и не стало понятно за последние 6 месяцев, зачем надо управлять данными в которых нифига не понимаем ? Я не знаю как написать точнее, лучше разделять и властвовать, т.е. определили модуль, подготовили юзер инфо, входные юзер данные, дали классы для темплейтов и унифицированного доступа в базу, на крайняк, если так секретно все, каждый модуль работет со свое базой, и пусть себе творит там все что хочет и как хочет, в такой ситации если модуль порит базу, то только свою а не соседних модулей... упали новости ну фиг с ними, но остальное цело. и главное скорость работы в десятки и даже сотни раз больше.

И последнее Мелкомягкие дали отличную идею Doc & View. Если View умеет показать, то может и отредактировать, а обновлением базы дело модуля. Потому сразу предупреждаю вопрос о редактировани данных через CMS ровно как и об их администрировании.

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

 

[desperado]

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

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

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

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

 

[GSL]

desperado нет... ни в коем случае не надо ничего перечеркивать, С/С++ тоже вначале делались на коленке в подвале, возможно PHP еще станет нормальным мощным инструментом... Но пока этого нет может не надо пробовать так сильно его мучать ?

кнопочка изменить определяется фактически не данными, объекта и не ядром, а правильностью написания View. Переложим таки часть логики на Template.

Если вызван этот метод, то опятьже он просто спросит у ядра а как там доступ у этого пользователь ? нет, так сразу CoreDump мыло админу в лог запись и т.д. Но ядро к этому отношения не имеет, это не его работа, его работа связать программиста с общими рескурсами, kernel, он и в африке кернел. Ведь в любой OS если нет прав например на запись, это не значит что нет комманды записать, это значит что комманда выдаст ошибку... именно это работа ядря... в нашем случае если комманда наша, то мы пишем проверку, если кернела, то он выполнит сам и вернет результат...

Все бы просто если бы не надо было работать с данными более чем 1 объект или 1 запись базы...но при работе с большими объемами это не годиться....

В данной конкретной модели реализации что вирусы, что нет однофигкственно, потому как ядро никак не защищает нашу информацию... так зачем тогда ядро Ядро может само игнорировать только тогда, когда уверенно может сказать что там твориться, да можно сделать так что все что можно изменить станет объектом зарегистрированным в системе, ну а теперь вы себе хоть примерно представляете что будет после того как вы попробуете написать 3 язычный портал ? с 1000 зарегистрированных пользователей ? где не только есть языковые пакеты, но и динамические поля, например, название или описание продукта ? и где список продуктов 1 000-10 000 штук ? одна только попытка вывесьт список товаров будет требовать такое колличесво ресурсов, что никакой кеш не спасет. тривиальная страница с 17 товарами генерилась от 0,5 до 1.2 сек.

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

 

[xRay]

desperado[/q]
Блин, тема система прав доступа на столько актуальна что аж жуть. Мне больше всего нравиться концепция Active Directory
. Я думаю это то что нам всем надо. И не ограничивает нас и гибка и т.д.
Я пока только у проекта iPhportal видел более менее нормальную систему прав доступа, ну плюс еще пару проектов.

 

[desperado]

довольно любопытный тред:
http://www.sitepoint.com/forums/showthread.php?t=162027

(правдо на англицком, в связи с пониманием кривого англицкого от немцов по доке в трех томах с пояснениями, мне как-то сложновато все усвоить)

псы - советую читать последовательно, а то сложно понять о чем идет речь (%

-~{}~ 18.06.04 12:08:

что-то все притихли...
продолжаем мысли в слух.

users_main:|user_id|user_login|user_pass|user_email|user_status|user_expiration|
groups:|group_id|group_name|group_status|
users_to_groups:|user_id|group_id|

actions:|action_id|action_name|

objects:|object_id|parent_id|user_id|class_id|object_name|
//здесь class_id - определяет тип объекта и его обработчик.
//user_id - определяет пользователя, который является owner'ом объекта и,
//          следовательно, к кому применять псевдо-группу - owner со своими правами
//parent_id - идентификатор родительского объекта

objects_users_to_action:|user_id|object_id|action_id|
objects_groups_to_action:|group_id|object_id|action_id|

все объекты наследуют права от родителей, если для них не прописаны они отдельно. тем самым, нам не требуется прописывать права для каждого объекта. на примере системы-форумов, нам достаточно прописать права для групп "Users" \ "Owners" \ "Moderators"... на уровне отдельного, конкретного форума и\или секции форумов. а все дочерние объекты будут их наследовать.

(к примеру)

+-+B-Board
  +-+Section-1
  | +-+Forum-1
  | | +-+Thread-1
  | | | +-Reply-1
  | | | +-Reply-2
  .....
  |
  +-+Section-n
  | +-+Forum-n
  | | +-+Thread-n
  | | | +-Reply-n
  | | | +-Reply-n
  | | |
  .....

В Целом, нам достаточно определить права пользователя для всей "Борды" (фактически - дефолтные настройки), а для конкретных случаев, прописывть их отдельно.

 

[Calipsio]

как в PHP коде оргонизовать это

users_main:|user_id|user_login|user_pass|user_email|user_status|user_expiration|
groups:|group_id|group_name|group_status|
users_to_groups:|user_id|group_id|
actions:|action_id|action_name|
objects:|object_id|parent_id|user_id|class_id|object_name|

Через класс, поделитесь кодом.. =)