Moodle

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, которая возвращает логическое значение, например, для установления того, показать ли ссылку на этот сценарий на другой странице.

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

<?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 (предотвращающее использование).

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

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

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

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

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