Роли

International Russian
1

Всем доброго дня.

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

Лично для меня не понятен этот абзац

Мне кажется было бы здорово если б для упрщения понимая этого абзаца добавить сюда некий график…

Потому как тут явная путаница возникает:

  • Элемент A — предок B

Значит А является родителем B ?

  • A состоит из B (A наследует права, представленные в B)

Это как ? тут же вроде этот текст программисты читают а не домохозяйки ?

Если А является родителем B то как же он может наследовать права которые представлены в В ?

  • В ней роли находятся на верхних уровнях, операции — на нижних

О каких уровнях идет речь, в предложении идущим после того, как читатель в голове только сумел представить картину кто и что наследует … ?

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

Потому как для меня все таки остается вопрос кто у кого и что наследует и на каком уровне … жесть.

Спасибо.

2

Переводил эту часть я. Вот оригинал:

Да.

Тут не дерево, о чём упомянуто, так что направление наследования тут может быть абсолютно любое.

Схема графа тут действительно не помешала бы, но её надо сначала добавить в оригинал.

3

Ну т.е. твое предложение написать об этом квангу ? я думаю у него вряд-ли будет время на эти мелочи…

Может из наших кто-то смог бы ??

Вот направление наследования тут тоже очень не просто сообразить.

т.е. правильно ли я понимаю что наследоваться может как вверх так и вниз ?

так и бошку то сорвать может … как это понять ?

наследуется в том направлении кому делает addChild?

вот к примеру из мануала




$role=$auth->createRole('admin');

$role->addChild('editor');

Правильно ли я читаю этот код:

  • к роли admin добавляем все привилегии editor’a ? Если так то направление наследования здесь понятна…

и еще вот этот:




$task=$auth->createTask('updateOwnPost','редактирование своей записи',$bizRule);

$task->addChild('updatePost');

Создаем задачу и к ней подключаем операцию ?

Как здесь понять направление унаследования ?

И зачем вообще эти два правила "связывать" ? Какая практическая польза от этого ? (cамое интересное что похожий вопрос практически одноврменно был поднят вот тут - http://www.yiiframework.com/forum/index.php?/topic/5116-rbac-just-cant-get-my-head-around-it/ )

В мануале это не затрагивается вообще - какая польза от именно этих двух (последних) строчек.

Вообще вся работа с RBAC’ом можно поделить на три составляющие

  1. Это создание иерархии

  2. Создание логики в коде (т.е. расставление фильтров, или иных способов осуществления контроля доступа)

  3. Назначение прав пользователям

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

Из прочитанного мною (доки, мануал и форум) все эти роли, операции и таски на самом деле носят свои названия сугубо для логики.

Т.е. на работу системы это как бы не влияет.

Если я правильно понимаю, то

  1. Пользователю можно назначить (assign) не только роль но и таск и операцию верно ?

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

Просто если все это верно то это вносит больше путаницы чем логики … ИМХО.

4

Да кстати я тут посмотрел было на расширение srbac - упал в осадок, я правда их демку только посмотрел … я вообще ничего не понял… Я не смог понять как им пользоваться :( допустим что это я такой кривой :(

Но ползая по нему, у меня появилась мысль:

такого рода интерфейс, вероятно единственное что должен делать это Создание иерархии "системы прав" (Однако как можно сделать ГУИ для граф? так что б юзер не запутался?)

  • assign существующего в системе пользователя к любому AuthItem.

И кстати если я правильно понял исключение (except) какого либо Authitem’а не возможно ?

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

5

Если дать готовый вариант — время у него найдётся. Как появится время - могу сделать. Если кто сделает раньше — я только за.

Да.

Да, так.

Направление определяется 1 в 1 как и в описанных выше случаях.

Так и есть.

Исключать невозможно, но это ничуть не мешает:

Есть A и B. Хотим в B всё, что есть в A кроме одной роли.

Выделяем всё из A кроме этой самой одной роли в C. Наследуем A и B от C. В A добавляем ту самую одну роль.

6

Cпасибо за ответы

один только вопрос остался без внимания

7

Этого вопроса я не понял.

8

смотри

$task=$auth->createTask(‘updateOwnPost’,‘редактирование своей записи’,$bizRule);

$task->addChild(‘updatePost’);

Здесь мы операцию updatePost делаем "ребенком" задачи updateOwnPost.

Я сегодня полез в сорцы посмотрел вся проверка держится на двух запросах

и если я все правильно понял то при проверке фреймворк берет AuthItem

смотрит есть ли такой у текущего пользователя, и если да то доступ разрешен,

а если нет то спускается по всем детям этого Item’а, и снова проверяет.

К примеру в мануале есть вот такие строки




$role=$auth->createRole('author');

$role->addChild('reader');

$role->addChild('createPost');

$role->addChild('updateOwnPost');

вот тут одним из наследников являеется

updateOwnPost

но чуть выше мы видели что у updateOwnPost есть свой ребенок updatePost

Значит ли это что у автора в итоге есть право выполнять и updatePost ?

и если нет то почему ???

По моей логике и после того как я посмотрел сорцы мне кажется что updateOwnPost

не должен иметь потомков.

9 



$task=$auth->createTask('updateOwnPost','редактирование своей записи',$bizRule);

$task->addChild('updatePost');


$role=$auth->createRole('author');

$role->addChild('updateOwnPost');

Наследуется снизу вверх:




author

  updateOwnPost

    updatePost
10

Это ты с чего взял ?

Есть какие-то более основательные объяснения ?

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