Принципы работы

Принципы работы - основные определения и объяснение принципов работы подсистемы управления привилегиями администраторов

Содержание

1. Введение
2. Действующие лица
3. Иерархия имён
4. Иерархия привилегий
5. Иерархия администраторов
6. Иерархия ролей
7. Свойства допустимости, определённости, предсказуемости
8. Проверка привилегий
9. Проверка полномочий
10. Передача и отзыв привилегий
11. Программист
12. Как скачать
13. Смотрите также

Введение

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

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

Но уже даже в этой системе мы можем наблюдать, что не все так просто с этими группами. Например, создатели курсов считаются преподавателями только в пределах тех курсов, которые они сами создали, а при просмотре других курсов они считаются студентами. Мы не можем для каждого конкретного преподавателя указать, может ли он добавлять в свой курс других преподавателей или же это может сделать только создатель курса. Для облегчения поиска нужных курсов эти курсы распределены по категориям (по папками), которые имеют иерархическую организацию. Если мы записываем человека в группу создателей курсов, то он может создавать курс в любой категории - мы не можем ограничить, внутри каких категорий он может создавать новые курсы. Создав новый курс, мы не можем записать на него сразу всю группу студентов, мы должны добавлять студентов по одному, выбирая их из !ВСЕХ! пользователей, зарегистрированных на сайте. Либо мы можем сообщить им кодовое слово, и тогда они сами себя добавят - но где гарантия, что это кодовое слово не станет известно посторонним? Есть также много других ограничений.

Эти ограничения возникли не на пустом месте.

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

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

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

Действующие лица

1. Пользователь - человек, обращающийся к сайту.

2. Зарегистрированный Пользователь - Пользователь, зарегистрировавшийся в системе и идентифицировавший себя путем указания своего логина и пароля.

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

4. Анонимный пользователь - Пользователь, который не указывал свой логин и пароль. В этой статье, если не указано, что пользователь является анонимным, то считается, что он является зарегистрированным пользователем.

5. Действие - запрос к скрипту, который приведет к изменениям в базе данных либо к получению некоторой информации. Например, редактирование текстов и редактирование новостей - это разные Действия, которые приводят к изменениям в базе данных. Просмотр IP-адреса, с которого другой Пользователь обращался к сайту - это Действие, которое приводит к получению информации.

6. Привилегия - это некоторая последовательность символов (строка). В зависимости от того, есть ли в базе данных запись с этой строкой, определяется возможность выполнения некоторого Действия.

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

8. Привилегия может быть разрешена, запрещена или о ней может не быть никакого упоминания. Когда говорится, что привилегия разрешена, запрещена или о ней есть некоторое упоминание, то фактически речь идёт о том, есть ли запись с этой привилегией в списке привилегий, и что стоит во второй колонке: плюсик или минусик.

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

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

    В старых версиях документации полномочия назывались словом «возможности».

11. Если для пользователя не разрешено ни одной привилегии, то он не обладает ни одной привилегией. Обратное не верно: если пользователь не обладает ни одной привилегией, то это не означает, что для него не разрешено ни одной привилегии.

12. Для Анонимного Пользователя не могут быть разрешены привилегии.

13. Роль - это список привилегий, который рассматривается в системе глобально и не привязывается к конкретным пользователям.

14. Набор ролей - перечень всех ролей, зарегистрированных в системе.

15. Группа пользователей - все Зарегистрированные Пользователи системы, обладающие привилегией принадлежности группе.

16. Администратор - Зарегистрированный Пользователь системы, обладающий хотя бы одной Привилегией.

17. Список Привилегий Администратора - список привилегий, который существует только для каждого отдельно взятого Администратора.

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

19. Когда говорится, что действие НЕ может быть выполнено Администраторами, то это означает, что в системе не может появиться ни одного Администратора, который может выполнить это действие.

20. Подсистема управления привилегиями администраторов - набор скриптов, при помощи которых производится управление Списками Привилегий Администраторов, Ролями, поиск Администраторов, обладающих заданной Привилегией и проверка обладания привилегией заданным Администратором.

Иерархия имён

1. Все привилегии, роли и группы имеют уникальные имена. По этим именам производится обращение ко всем привилегиям, ролям и группам в системе.

2. Каждое Имя состоит из Слов.

3. Слова имени разделяются между собой символом “.” (точка).

4. В Словах могут использоваться большие и маленькие буквы латинского алфавита, цифры, символы “_” (подчеркивание) и “-” (минус). Регистр букв имеет значение.

5. Максимальная длина имени вместе с разделителями - 255 символов.

   Минимальная длина Слова - один символ. Это означает, что в имени не допустима точка в самом начале, две точки подряд внутри имени и точка в конце.

6. Уровень имени - количество слов в имени.

7. Имя А является родительским по отношению к имени B, если уровень имени А меньше уровня имени B и первые слова (слева) имени В совпадают с первыми (слева) словами имени А. Например, имя bbs является родительским для имени bbs.theme, bbs.topic и bbs.theme.remove. Имя bbs.theme является родительским для имени bbs.theme.remove.

8. Имя А является дочерним по отношению к имени В, если имя В является родительским по отношению к имени А.

9. Имена принадлежат одной группе имён, если у этих имён есть некоторое общее родительское имя. Это общее родительское имя является именем группы.

Иерархия привилегий

1. Каждая привилегия имеет уникальное имя. По этому имени производится обращение ко всем привилегиям в системе. Эти имена имеют иерархическую организацию. Иерархия привилегий определяется иерархией имён привилегий.

2. Базовая Привилегия - привилегия, имя которой записано в скриптах и не может быть изменено Администраторами.

3. Динамическая Привилегия - привилегия, имя которой может быть изменено Администраторами.

4. Динамические привилегии всегда являются Дочерними по отношению к Базовым.

Иерархия администраторов

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

2. Каждая группа имеет уникальное имя. По этому имени производится обращение ко всем группам в системе. Эти имена имеют иерархическую организацию.

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

4. Зарегистрированный пользователь принадлежит группе, если этот пользователь обладает привилегией принадлежности группе.

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

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

7. Если Зарегистрированный пользователь не принадлежит ни одной группе, то он принадлежит группе со специальным зарезервированным именем nogroup.

8. Привилегия управления группой не требуется для управления своими привилегиями.

Иерархия ролей

1. Каждая роль имеет уникальное имя. По этому имени производится обращение ко всем ролям в системе. Эти имена имеют иерархическую организацию.

2. Для управления разрешением и запретом на выполнение роли существует привилегия выполнения роли.

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

4. Если список привилегий А объединяется со списком привилегий B, то в результате получатся список С. Список С разрешает все привилегии, которые разрешены в списке А и не запрещены в списке В или разрешены в списке В и не запрещены в списке А. Список С запрещает все привилегии, которые запрещены в списке А или запрещены в списке В.
   
   В случае объединения списков можно говорить, что запрет привилегии имеет выше приоритет, чем её разрешение.

5. Если уровень роли больше одного, то эта роль наследует привилегии родительской роли. Такое наследование называется простым наследованием.

6. Выполнение роли разрешено, если разрешена привилегия выполнения роли.

7. Выполнение роли запрещено, если запрещена привилегия выполнения роли.

8. Если в списке привилегий некоторой роли А разрешено выполнение некоторой роли В, то роль А наследует привилегии роли В. Такое наследование называется разрешением роли.

9. Если в списке привилегий некоторой роли А запрещено выполнение некоторой роли В, то роль А наследует привилегии роли В. При этом считается, что в роли В запрещены все привилегии, о которых в роли В есть хоть какое-нибуь упоминание: и те привилегии, которые разрешены и те привилегии, которые запрещены. Такое наследование называется запретом роли.

10. Если для некоторой роли А Разрешена или Запрещена некоторая роль В, то роль В называется дружественной ролью по отношению к роли А.

11. Если для некоторой роли A указана более чем одна Дружественная роль, то списки привилегий всех дружественных ролей объединяются перед тем, как быть наследованными ролью А. Таким образом, если в списке роли А нет явного упоминания о некоторой привилегии Х, то для роли А привилегия Х будет запрещена, если эта привилегия запрещена хотя бы для одной дружественной роли.

12. Разрешение роли и Запрет роли называется дружественным наследованием.

13. Дружественное наследование имеет выше приоритет, чем простое наследование. Это означает, что если в Дружественной роли есть некоторое упоминание (разрешение или запрет) о некоторой привилегии Х, то упоминание о привилегии Х будет проигнорировано в родительской роли.

Свойства допустимости, определённости, предсказуемости

1. Свойство о наследовании пустых списков привилегий.

   Если некоторый список А наследует список В, и список В - пуст, то в результате получится список С, совпадающий со списоком А: С===А.

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

   В списке С будут запрещены все привилегии, которые запрещены в списке А или запрещены в списке В и не разрешены в списке А. Поскольку список В пуст, то в нем не запрещены никакие привилегии. Это означает, что в списке С будут запрещены все те и только те привилегии, которые запрещены в списке А.

2. Свойство о наследовании списков с совпадающими привилегиями.

   Если некоторый список А наследует список В, и списке В есть привилегии, которые упоминаются в списке А, то при построении списка - результата наследования С, соответствующие привилегии списка В можно проигнорировать, или просто удалить из списка В.

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

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

3. Свойство о наследовании одинаковых списков привилегий.

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

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

4. Свойство однозначности наследования пустых и одинаковых списков привилегий.

   Если некоторый список А наследует список В, и список В совпадает со списком А, то список В можно принять пустым, результат наследования (список С) от этого не изменится.

   Согласно свойству о наследовании пустых списков привилегий и свойству о наследовании одинаковых списков привилегий, список С будет совпадать со списком А (С===А) не зависимо от того, является ли список В пустым или список В совпадает со списком А (А===В).

5. Свойство о рекурсивном наследовании.

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

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

   Если список А наследует сам себя косвенно, через один список, то можно сказать, что список А наследует список D а список D наследует список B при B===A. Согласно свойству о наследовании списков с совпадающими элементами, если в списке А есть некоторое упоминание (разрешение или запрет) некоторой привилегии Х, то упоминание об этой привилегии можно удалить из списка D. Поскольку привилегия Х будет удалена из списка D, то её упоминание в списке B нас также не интересует. Поэтому привилегию Х можно удалить также и из списка В. Поскольку В===А, то из списка В можно удалить все привилегии и оставить список В пустым.

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

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

7. Свойство набора ролей о допустимости.

   Любой набор ролей допустим.

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

8. Свойство объединения о порядке следования списков.

   Порядок объединения списков не имеет значения.

9. Свойство определённости набора ролей.

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

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

10. Свойство предсказуемости ролей.

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

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

Проверка привилегий

1. Операция по проверке того, обладает ли Администратор заданной привилегией, называется проверкой привилегий.

2. Если не указано иное, то считается, что все привилегии запрещены для всех пользователей.

3. Каждый элемент Списка Привилегий Администратора может быть дополнительно ограничен списком масок подсетей. Если ip-адрес, с которого Администратор обращается к системе, не соответствует ни одной подсети из списка подсетей, то соответствующий элемент списка привилегий администратора игнорируется и считается, что об этой привилегии нет никакого упоминания.

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

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

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

7. При проверке привилегий считается, что Администратор обладает привилегией, если для него разрешена проверяемая привилегия или любая родительская привилегия. Такая проверка привилегий используется по умолчанию и называется строгой проверкой привилегий, проверкой родительской привилегии или просто проверкой привилегий. Например, если в администратору разрешена привилегия text.view, то считается, что он обладает привилегиями text.view.a, text.view.b, text.view.a.b.c и т.п. Если выполняется проверка того, обладает ли администратор привилегией text.view.a.b.c, то ответ будет «обладает», если для этого администратора разрешена любая из привилегий text.view.a.b.c, text.view.a.b, text.view.a, text.view или text.

8. Для выполнения некоторых Действий от Администраторов может потребоваться обладание любой дочерней привилегией. Например, администратор может получить доступ к редактору списка параметров статей в случае, если администратор может редактировать хотя бы один любой параметр: администратор должен обладать привилегией text.param (для редактирования любых параметров) или любой дочерней привилегией, например text.param.noindex или text.param.protect для редактирования параметра noindex или параметра protect соответственно.

   Такая проверка привилегий называется проверка дочерней привилегии.

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

   Например, если выполняется проверка того, обладает ли администратор дочерней привилегией для привилегии text.view.a, то ответ будет «обладает», если для этого администратора разрешена любая из привилегий text.view.a.b.c, text.view.a.b, text.view.a, text.view или text.

   При строгой проверке привилегии text.view.a ответ был бы «не обладает», если бы для администратора были разрешены привилегии text.view.a.b.c или text.view.a.b, но не были бы разрешены привилегии text.view.a, text.view и text.

9. Cтрогая проверка привилегий и проверка дочерней привилегии выполняются на основании итогового списка привилегий администратора.

Проверка полномочий

1. Операция по проверке того, может ли Администратор выполнить некоторое Действие, называется проверкой полномочий.

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

3. Проверка полномочий выполняется перед выполнением Действия. Действие будет или не будет выполнено в зависимости от результата проверки полномочий.

4. В некоторых случаях проверку полномочий удобно выполнить заранее, например, чтобы принять решение о том, показывать ли Администратору ссылку на страницу администрирования. В таком случае проверка полномочий выполняется несколько раз: при отображении ссылки и непосредственно перед выполнением Действия. Отображение ссылки в таком случае рассматривается как отдельное Действие.

5. Взаимодействие всех этапов проверки перед выполнением действия представлено на рисунке:

   Проверка разрешения / запрета привилегии
↓
Проверка обладания привилегией
↓
Проверка полномочий

6. На этапе проверки разрешения / запрета привилегии привилегии могут находиться в одном из трех состояний: «разрешена», «запрещена» или «не упоминается». Фактически на этом этапе мы работаем со списками привилегий. При редактировании списков привилегий администраторов мы указываем, какие из привилегий будут разрешены, какие - будут запрещены, а о каких привилегиях не будет упоминания.

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

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

7. На этапе проверки обладания привилегией привилегии уже могут быть только в одном из двух состояний: администратор обладает или не обладает этой привилегией.

   На этом этапе строится итоговый список привилегий администратора.

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

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

8. Этап проверки полномочий предназначен для того, чтобы скрыть понятие «привилегия» от всех остальных подсистем и отвечать только на вопросы о том, может ли данный пользователь выполнять какое-то Действие. Например, «может ли пользователь редактировать эту статью?». В качестве параметра процедуре проверки полномочий передается, например, имя файла статьи. На основании этого имени файла процедура проверки полномочий формирует имя привилегии, проверяет, обладает ли пользователь этой привилегией и в зависимости от результата проверки говорит, может ли пользователь отредактировать эту статью. Возможны также и более сложные случаи, когда результат проверки полномочий зависит от нескольких разных параметров, когда для выполнения действия требуется обладание одной из нескольких привилегий или одновременное обладание несколькими привилегиями. На этом же этапе выполняются такие проверки, как «является ли пользователь владельцем сообщения?».

   Этап проверки полномочий выполняется той системой, для которой требуется распределение привилегий. На этом этапе привилегии делятся на базовые и на динамические. Базовые привилегии задаются в процедурах проверки полномочий, а динамические привилегии составляются на этом этапе с учетом динамических данных, например, имён файлов.

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

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

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

Передача и отзыв привилегий

1. Для каждой привилегии администратор может дополнительно получить привилегию управлять разрешением и запретом этой привилегии у других администраторов и в ролях. Такая Привилегия называется привилегией управления привилегиями, или просто Привилегией Управления.

2. Операция разрешения привилегии в Списке Привилегий Администратора или в роли называется Передачей Привилегий.

3. Операция запрета, привилегии в Списке Привилегий Администратора или в роли называется Отзывом Привилегий.

4. Передача и Отзыв привилегий - это Действия.

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

6. Если администратор обладает Привилегией Управления, то он может Передать или Отозвать эту и любую Дочернюю Привилегию у Администраторов, которые входят в группы, на управление которыми у этого администратора есть привилегии.

7. Если администратор обладает Привилегией Управления, то он может Передать или Отозвать эту и любую Дочернюю Привилегию у себя.

8. Администраторы могут создавать новые Динамические Привилегии.

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

Программист

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

2. Программист - это человек, имеющий доступ к страницам программиста.

3. Доступ к страницам программиста возможен только с набора конкретных ip-адресов. Эти ip-адреса записываются в скриптах и не могут быть изменены Администраторами.

4. Пароли зарегистрированных пользователей хранятся в базе данных. Пароль программиста хранится в скриптах.

5. Программист не является Администратором системы.

6. Программист не является Зарегистрированным Пользователем системы.

7. Программист не является Анонимным Пользователем системы.

8. Программист может вносить изменения в скрипты. Никакие другие Пользователи вносить изменения в скрипты не могут.

9. Программист может создавать новые Базовые Привилегии. Никакие другие Пользователи не могут создавать новые Базовые Привилегии.

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

11. Программист может передать любому Зарегистрированному Пользователю привилегию admin. Наличие этой привилегии позволяет управлять любыми привилегиями, управлять пользователями любых групп и управлять любыми ролями.

Как скачать

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

Однако, Вы можете получить бесплатную систему на php+mysql с открытыми исходными кодами, в которой реализована описанная система управления привилегиями администраторов:
http://popoff.donetsk.ua/light

Основная проблема, решение которой необходимо для выделения подсистемы управления привилегиями администраторов в отдельную библиотеку, состоит в том, что интерфейс редактирования ролей и списков привилегий использует встроенные в систему popoff.donetsk.ua/light модули шаблонизатора, поддержки многоязычности, подсистему отладки, службу управления аккаунтами пользователей, используется собственная схема межбиблиотечной коммуникации.

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

Смотрите также

Таблицы, использованные при реализации этой системы
passport_privilege, passport_role_list, passport_role_privilege

Бесплатная система на php+mysql, в которой реализована описанная система управления привилегиями администраторов
http://popoff.donetsk.ua/light

Доступ в программах
http://www.citforum.ru/programming/digest/access.shtml

phpGACL - русская документация
http://php.russofile.ru/phpGACL.html

Последняя модификация: 14.08.07 00:31

Не проходите мимо! Оставьте Ваш комментарий в форуме! >>>