Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com
  • Подбор персонала
  • Подбор персонала, кадровый консалтинг. Агентство по подбору персонала
  • срочнонайм.рф

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

Moodle

Оригинал: Moodle
Автор: Tim Hunt
Перевод: А.Панин

13.2. Система ролей и разрешений приложения Moodle

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

Строка 3: Получение контекста

$context = context_system::instance();                        // 3

В приложении Moodle пользователи могут иметь различные права в различных местах. Например, пользователь может быть преподавателем на одном курсе и студентом на другом и, таким образом, иметь различные права в каждом из мест. Эти места называются контекстами (contexts). Контексты в приложении Moodle формируют иерархию, очень похожую на иерархию директорий в файловой системе. На верхнем уровне находится контекст системы (System context) (и, так как данный сценарий не достаточно хорошо интегрирован с приложением Moodle, он использует именно этот контекст).

В системном контексте находится некоторое количество контекстов для различных категорий, которые создаются для организации курсов. Они могут быть вложенными, поэтому категория может содержать другие категории. Контексты категорий (Category contexts) также могут содержать контексты курсов (Course contexts). Наконец, каждое действие в рамках курса имеет свой контекст модуля (Module context).

Контексты
Рисунок 13.3: Контексты

Строка 4: Проверка того, имеет ли пользователь разрешение на использование данного сценария

require_capability('local/greet:begreeted', $context);        // 4

При наличии контекста - соответствующей части приложения Moodle - разрешение может быть проверено. Каждый набор функций, который предоставляется или не предоставляется пользователю, называется возможностью (capability). Проверка возможностей позволяет реализовать более точный контроль доступа, чем базовые проверки, выполняемые с помощью функции require_login. Наш пример расширения имеет только одну возможность: local/greet:beegreeted.

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

Как администратор устанавливает то, какой пользователь имеет какие возможности? Ниже приведен список действий, которые выполняет функция has_capability (по крайней мере, концептуально):
  1. Начинается работа с действующим контекстом.
  2. Извлекается список ролей, которыми пользователь обладает в рамках данного контекста.
  3. После этого проверяется то, какими разрешениями обладает пользователь в каждой роли в рамках данного контекста.
  4. Эти разрешения объединяются для формирования финального ответа.

Описание возможностей

Как видно из примера, расширение может описывать новые возможности, соответствующие предоставляемым расширением функциям. В каждом расширении приложения Moodle присутствует поддиректория для кода с именем db. Она содержит всю информацию, требующуюся для установки или обновления расширения. Одним из файлов, хранящих эту информацию, является файл с именем access.php, который описывает возможности. Ниже приведено содержимое файла access,php из состава нашего расширения, который находится в директории local/greet/db/access.php:
<?php
$capabilities = array('local/greet:begreeted' => array(
    'captype' => 'read',
    'contextlevel' => CONTEXT_SYSTEM,
    'archetypes' => array('guest' => CAP_ALLOW, 'user' => CAP_ALLOW)
));

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

Роли

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

В рамках определенного курса вы можете быть студентом и это соответствие роли будет актуально для контекста курса и всех контекстов модулей в нем. В другом курсе, однако, вы можете выступать в другой роли. Например, Mr Gradgrind может быть преподавателем курса "Facts, Facts, Facts", но при этом быть студентом курса профессиональной разработки "Facts Aren't Everything". Наконец, пользователю может быть предоставлена роль модератора в одном определенном форуме (в рамках контекста модуля).

Разрешения

Роль описывает разрешение (permission) для каждой возможности. Например, роль преподавателя наверняка установит значение разрешения ALLOW (позволяющее использовать) возможность moodle/course:manage, а роль студента - нет. Однако, и студенту и преподавателю будет доступна возможность mod/forum:startdiscussion.

Роли обычно описываются глобально, но они могут быть описаны повторно в каждом из контекстов. Например, определенный ресурс wiki может быть открыт только для чтения для студентов с помощью изменения значения разрешения для возможности mod/wiki:edit роли студента в рамках контекста этой системы wiki (контекста модуля) на значение PREVENT (предотвращающее использование).

Существуют четыре значения разрешения:
  • NOT SET/INHERIT (неустановленное/наследуемое значение, являющееся стандартным)
  • ALLOW (разрешающее значение)
  • PREVENT (запрещающее значение)
  • PROHIBIT (запрещающее, не изменяемое в подконтекстах значение)

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

Объединение разрешений

В конечном счете разрешения для всех ролей, в которых пользователь выступает в активном контексте, объединяются.
  • Если любая роль использует значение разрешения PROHIBIT для возможности, возвращается логическое ложное значение (false).
  • В ином случае, если любая роль использует значение разрешения ALLOW для возможности, возвращается логическое истинное значение (true).
  • В других случаях возвращается логическое ложное значение (false).

Условия использования значения PROHIBIT следующие: представьте, что пользователь создает оскорбительные сообщения на множестве форумов и нам нужно немедленно прекратить это. Мы можем создать роль Naughty, в рамках которой установить значение PROHIBIT для возможности mod/forum:post и других аналогичных возможностей. После этого мы присваиваем эту роль нарушающему порядок пользователю в системном контексте. Таким образом мы можем удостовериться в том, что этот пользователь не сможет написать ни одного сообщения ни в одном из форумов. (После этого мы свяжемся со студентом и в том случае, если получим от него удовлетворяющий нас ответ, сможем удалить соответствие этой роли, после чего он вновь сможет использовать систему.)

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


Далее: Вернемся к нашему примеру сценария


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

Комментарии отсутствуют