[Закрыть]
 
popoff.donetsk.ua
Ходил ли Карлсон по крыше?
Начало | Новости | Статьи | Форум | Опросы | Карта сайта | Обо мне
popoff.donetsk.ua - Форум - Программирование на PHP - Как формируется итоговый список привилегий администратора?

Как формируется итоговый список привилегий администратора?

форумы popoff.donetsk.ua
Страницы: [1]
<< Новый  |  Старый >>  |  Ответ не возможен

Внимание! Этот топик устарел. Пожалуйста, создайте новый топик, чтобы задать интересующий Вас вопрос.

Автор Сообщение
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1599
Как формируется итоговый список привилегий администратора?

Мне не понятен ещё один момент. В каком отношении находятся привилегии, напрямую назначенные администратору, и привилегии,  в назначенных ему ролях? Они наследуются, или объединяются, и если наследуются, что в какой последовательности наследуется?
Например, разрешена или запрещена будет привилегия test_priv1 (test_priv2), если:

<p>[uid]	[b_mode]	[s_privilege]
  1    1   test_priv1
  1    0   test_priv2
  1    1   role.test_role</p>

Для role.test_role (k_role = 1)

<p>[k_role]	[s_privilege]	[b_mode]
    1   test_priv1    0
    1   test_priv2    1</p>


Этот момент в статье вообще упущен :(

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1600

В пункте 6 раздела «Проверка привилегий» сказано, что

Итоговый список привилегий администратора может быть рассмотрен как роль с именем первого уровня. Все правила формирования списка привилегий ролей верны при формировании итогового списка привилегий администратора.


Ну а дальше Вам следует внимательно читать раздел «Иерархия ролей», там всё расписано, когда что чем наследуется, а когда что с чем объединяется.

Для Вашего примера у пользователя привилегия test_priv1 будет всегда разрешена, а привилегия test_priv2 - всегда запрещена, не зависимо от содержимого роли test_role.

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1601

В пункте 6 раздела «Проверка привилегий» сказано, что

Итоговый список привилегий администратора может быть рассмотрен как роль с именем первого уровня. Все правила формирования списка привилегий ролей верны при формировании итогового списка привилегий администратора.

popoffфорумы popoff.donetsk.ua


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

В п.5 сказано:

Итоговый список привилегий администратора - это список привилегий, в котором учитывается Список Привилегий Администратора и набор всех ролей системы. При этом используются операции объединения и наследования списков привилегий.


Исходя из этого Итоговый список привилегий администратора это уже всё, последняя стадия, дальше уже ничего не определяется, это уже и  «Список Привилегий Администратора и
    набор всех ролей
»! Зачем его тогда рассматривать как «роль с именем первого уровня»?

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

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1602

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

Selectфорумы popoff.donetsk.ua


У меня нигде не сказано, что этот список является родительской ролью.

Приведённая в п.6 фраза означает то и только то, что правила формирования итогового списка привилегий администратора - такие же, как и правила формирования списка привилегий ролей с именем первого уровня. Впрочем, я повторяюсь, но это только потому, что ты к этой моей фразе добавляешь, что итоговый список является для кого-то родительским. В статье указано, что «правила формирования - такие же, как и ...», а не «он является родительским для ...».

Эту фразу следует воспринимать как аналогию. Не введя эту аналогию, мне пришлось бы копировать всё содержимое раздела «Иерархия ролей», описывая специально технологию наследования для итогового списка привилегий администратора. А эта технология - одинаковая и для ролей с именем первого уровня, и для итогового списка привилегий администратора. Именно для того, чтобы не повторять содержимое раздела «Иерархия ролей», я и рассматриваю этот список как «роль с именем первого уровня». Если не рассматривать так, то нужно будет копировать один и тот же текст дважды.

~~~~~ 22 Сен 2006, 18:20 ~~~~~

Select,

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

Selectфорумы popoff.donetsk.ua

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

Однако, время, которое я могу потратить на разъяснение этого материала, очень сильно ограничено. И рисовать схемы у меня просто нет времени, да и желания, если честно, тоже - на мой взгляд, я расписал всё достаточно подробно. Да и сложность, кстати, именно в этом и состоит: для меня любой вопрос по этой системе - тривиален; мне нужно приложить очень много усилий, гораздо больше, чем Вам, чтобы понять, что в моих описаниях может быть непонятным.

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

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1603

Всё-равно не понятно зачем рассматривать «Итоговый список привилегий администратора как роль с именем первого уровня» и вводить аналогию, если список уже итоговый и его формирование окончено, расписывать ничего больше не надо? Может имеется в виду не «Итоговый список...», а просто «Список...»?

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

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1604

Всё-равно не понятно зачем рассматривать «Итоговый список привилегий администратора как роль с именем первого уровня» и вводить аналогию, если список уже итоговый и его формирование окончено, расписывать ничего больше не надо? Может имеется в виду не «Итоговый список...», а просто «Список...»?

Selectфорумы popoff.donetsk.ua

Для того, чтобы не повторять дважды содержимое раздела «иерархия ролей».

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

Selectфорумы popoff.donetsk.ua

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

~~~~~ 22 Сен 2006, 18:46 ~~~~~

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

~~~~~ 22 Сен 2006, 19:05 ~~~~~

Я, кажется, понял, в чём состоит неточность аналогии и внёс изменения в статью:

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

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1605
popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1606

По поводу верхней картинки.

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

Список привилегий администратора наследует привилегии, которые берутся из дружественных ролей. То есть, сама по себе привилегия существует внутри дружественной роли, и оттуда переходит в список привилегий администратора.

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

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

Кстати, список ролей у меня никак не отделяется от списка привилегий. То есть, в том списке, который видит пользователь на экране, да и по описанию, разрешение и запрет роли - это то же самое, что и разрешение и запрет любой другой привилегии. То есть:
allow admin
allow passport
allow role.a
allow text.edit
allow xmlfilter
Роль как бы растворена среди всех прочих привилегий. Может, имеет смысл и на рисунке обозначить, что в самом списке существует привилегия, которая разрешает роль role.a, role.b, role.a.1 и т.п., а сами эти роли вычисляются отдельно, наследуя какие-то другие списки и объединяясь между собой. Хотя, как это изобразить графически, я не знаю...

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

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

~~~~~ 23 Сен 2006, 19:21 ~~~~~

Да, и ещё одно, третье «кстати».

Раз уж Вы занялись документацией, то обратите внимание на добавленное мной одно TODO:
http://popoff.donetsk.ua/text/work/libs/passport/privilege/todo.html
Его исправление повлияет на порядок определения того, является ли одна привилегия дочерней по отношению к другой и, возможно, будет учитываться также при наследовании ролей и привилегий.

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1608

Теперь правильно: «Схема формирования итогового списка привилегий администратора 2»?

Расписывать подробнее ещё рано. Мы ещё не разобрались с нашими баранами (тоесть группами).

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1609

Ну, я думаю, что, в целом нормально.

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1610

Теперь вернёмся к моему примеру. Все пользователи моего ресурса принадлежат какой-то компании. Внутри компании он принадлежит определённому отделу.
Первое. Необходим механизм для назначения привилегий сразу всем пользователям компании, так чтобы их НЕЛЬЗЯ было переопределить явным назначением привилегий пользователю.
Второе. Необходим механизм для назначения привилегий сразу всем пользователям компании, так чтобы их МОЖНО было переопределить явным назначением привилегий пользователю.

Если со вторым проблем не возникает, то с первым есть определённые сложности.

После долгих мучительных размышлений, я нашёл один вариант, но выглядит он малоестественно:
Схема ролевой группировки пользователей для управления их привилегиями

Ты уверял что данную задачу можно решить в твоей системе. Да можно, но является ли такой метод удобным? Можешь предложить другой вариант?
Конечно можно допустить возможность прямого назначения привилегий (отменить запреты на схеме), что даст дополнительную гибкость методу, но тогда легко потерять логику и это не соответствует требованиям (недокументированный функционал). И даже не отменяя запреты, нет гарантии, что этого не произойдёт по ошибке.

Ещё остаётся нерешённая проблема с управлением пользователями по отделам.

Кстати, предложенный мною метод в теме «В системе управления привилегий не хватает управления группами пользователей» позволяет решить все обозначенные проблемы (только с подгруппами ещё не до конца додумал, но должно получится).

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1613

Первое. Необходим механизм для назначения привилегий сразу всем пользователям компании, так чтобы их НЕЛЬЗЯ было переопределить явным назначением привилегий пользователю.

Selectфорумы popoff.donetsk.ua

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

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

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

Собственно, вот и решение. Выдаём не одну привилегию, которую хотим зафиксировать, а сразу две:
1. Отзываем у всех привилегию, которая разрешает редактировать нашу важную привилегию
2. Привилегию, которую мы хотим передать или отозвать

По поводу картинки.

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

По поводу термина «Итоговый список привилегий» - это внутренний список, он существует только для системы управления привилегиями. Есть просто список привилегий - это то, что пользователь видит на экране. Он вводит много таких списков для разных ролей, которые находятся между собой в разных отношениях. Итоговый список - это список с учётом всех наследований и объединений, который нигде не выводится.

Вообще, судя по картинке, ты предложил ввести ещё один некий список (то есть, «итоговая роль»), который находился бы ближе к пользователю, чем доступный для всех список (то есть, как я понял, «роль пользователя»); ты также предложил вторичную и первичную роли компании с целью, что сначала из вторичной роли компании наследуются привилегии ролью пользователя (это даёт возможность решения твоего «ВТОРОЕ»). После этого список наследуется «первичной ролью» (это даёт возможность решение твоего «ПЕРВОЕ»).

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

Список привилегий администратора содержит в себе две привилегии:
role.All.UserLogin
role.Company
Всем админам запрещается вносить в списки привилегий пользователей какие-либо другие привилегии. Эти привилегии должен назначать тот, кто может редактировать список привилегии роли Company.

В таком случае, роль All.UserLogin - это то, что на твоей картинке обозвано словом «Роль пользователя»

Роль All - это вторичная роль компании.

А роль Company - это первичная роль компании.

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

~~~~~ 25 Сен 2006, 18:08 ~~~~~

Кстати, предложенный мною метод в теме «В системе управления привилегий не хватает управления группами пользователей» позволяет решить все обозначенные проблемы (только с подгруппами ещё не до конца додумал, но должно получится).

Selectфорумы popoff.donetsk.ua

Имхо, незачем так мудрить с ролями. Целое дело потом запомнить, кому куда что прописал и откуда что взял.

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1616

Итак, для уточнения возвращаемся к одному из основных вопросов, на который я думал что получил однозначный ответ. Для однозначности воспользуюсь примером, «потому как либо что».

Есть список привилегий:

test_priv_1
test_priv_2
role.test_role_1

Предположим что в списке привилегий роли role.test_role_1 нету дружественных ролей.

В каких отношениях находятся привилегии «явно заданные пользователю» test_priv_1 и test_priv_2, со списком привилегий роли role.test_role_1 ? Отношения НАСЛЕДОВАНИЯ или ОБЪЕДИНЕНИЯ?
Именно это в документации никак не обозначено.

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1619

В документации написано, что:
1. список привилегий администратора - это роль.
2. роль НАСЛЕДУЮТ списки дружественных ролей
3. роль role.test_role_1 - это дружественная роль

следовательно

список привилегий администратора НАСЛЕДУЕТ списки роли role.test_role_1

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1625

Список привилегий администратора содержит в себе две привилегии:
role.All.UserLogin
role.Company


Это работать не будет, так как привилегии роли компании (role.Company) должны иметь выше приоритет чем привилегии пользователя (role.All.UserLogin). В данном случае запрет привилегии в role.All.UserLogin перекроет её разрешение в role.Company.

popoff
Yuri
Июл, 2004
Сообщений: 940
popoff url://forum.message:1627

А, ну да. Действительно так

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

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

По большому, этот вариант практически один к одному, мне кажется, совпадает с предложенным Вами. Но у него есть известны недостаток - если, к примеру, мы хотим выдать по такой же схеме не для всего предприятия, а для всего отделения, включая подотделения. Тут уже предчувствую предложение прикрутить для этих целей то, что у меня сейчас называется словом «группа». Но там с группами не всё так просто - их имена указываются в списках привилегий пользователей, а, значит, могут появиться админы, которые будут их удалять, и тогда распределение привилегий по группам не будет работать.

Я не хотел бы, чтобы «группы» в моём текущем понимании как-то перегружались ролями, я хотел бы, чтобы понятие «кто кем может управлять» НИКАК НЕ ПЕРЕСЕКАЛОСЬ с понятием «кто что может делать». Пересечение - означает, что одно зависит от другого, а это снижает гибкость.

Как вариант - можно было бы добавить какое-нибудь третье понятие, к примеру, «роли» и «группы» - в их текущем привычном понимании, а, к примеру, «менеджеры» - для обозначения кто кем может управлять. Но такое решение наталкивает на мысли о том, что фактически у нас есть разные роли с разным приоритетом. Вводя, к примеру, «группы» - как более важные - мы фактически говорим, что у нас есть роли двух уровней: важные (для всего предприятия, которые нельзя переопределить) и менее важные (которые можно переопределить). Оно, как бы, наверное, и не надо будет, но тут хорошо бы помыслить над тем, что таких уровней может быть много, то есть может потребоваться задать какую-нибудь важную привилегию, которая определена для всех, но даже в группах её переопределить нельзя.

В целом, я, разрабатывая свою систему, шёл по пути максимальной простоты реализации. Хотя описание получилось длинным и мутным, по сути там всё чрезвычайно просто. Вы видите, что таблиц там всего три. Объём ядра системы - меньше 20 КБ. Всё задаётся универсальным способом. Самые сложные процедуры на данный момент, кстати - это процедуры, которые возвращают список администраторов, которые обладают заданной привилегией. Там с этими процедурами, если честно, жуть, думаю, они занимают примерно половину всего объёма ядра системы привилегий, если не больше; их особенность на данный момент состоит в том, что любая модификация системы может привести к необходимости писать их с нуля. Не хотелось бы их усложнять: чем сложнее система, тем больше в ней ошибок, а для системы привилегий ошибки никак не допустимы. Если в форуме будет глючить отправка сообщений, то это будет видно всем. А если система привилегий даст лишний положительный ответ, то это может быть не выявлено годами, и многие люди могут втихую этим глюком пользоваться. А администратор этого может долго не замечать, так как у него всё работает нормально, да и у пользователей, в целом, тоже всё правильно - просто у них есть какие-то возможности, о которых админ не подозревает.

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

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

Внимание! Этот топик устарел. Пожалуйста, создайте новый топик, чтобы задать интересующий Вас вопрос.

Страницы: [1]
<< Новый  |  Старый >>  |  Ответ не возможен
Вход
Поиск[?]:
Программное обеспечение любой сложности
koins.com.ua