Организация управления доступом в 1С-Битрикс

• Предисловие
• Права и роли в ПО
• Операции и уровни доступа в 1С-Битрикс УС
• API для работы с операциями и уровнями доступа
• Привязки (BINDING)
  • Помощь и благодарности

Предисловие

В декабре 2011 года компания 1С-Битрикс выпустила Управление Сайтом 11.0.10, и вывела управление правами доступа собственных модулей на новый уровень. К “классической триаде” обязательных методов любого модуля (InstallDB, InstallEvents и InstallFiles) добавился еще один, мало кому из программистов сегодня известный — InstallTasks. О нем и всех его аспектах и пойдет сегодня речь, но сначала немного теории.

Права и роли в ПО

Организация управления доступом на основе ролей (RBAC, Role Based Access Control) в ПО известна уже давно и в том или ином виде знакома большинству программистов. Почитать про нее можно в интернете, здесь же отметим ключевые ее особенности:

1. Каждому пользователю системы присваивается Роль;
2. Каждая роль содержит набор Прав или Разрешений;
3. При выполнении любых операций происходит проверка именно Прав и Разрешений.

Операции и уровни доступа в 1С-Битрикс УС

Сразу нужно запомнить — права в исходном коде УС называются не иначе как “operations” или “операции”, роли — “tasks” или “уровни доступа”. Управление операциями (их добавление или удаление) через панель управления невозможно — только через API системы (использование метода CModule::InstallTasks как раз является замечательным примером такого использования). А вот создание уровней доступа возможно не только через API, но и вручную, силами администратора или любого другого привилегированного пользователя по пути “Настройки->Пользователи->Уровни доступа”. Эта страница должна быть знакома тем специалистам, которые хоть раз да настраивали на сайте доступ для “контент-менеджера” или “модератора” — сотрудников, у которых должен быть доступ в панель управления, но ограниченный. Такая настройка занимает совсем немного времени и не требует участия программиста.

В БУС нельзя напрямую назначать конкретные права на операции конкретным пользователям (в полном соответствии c RBAC). Связь производится через два промежуточных звена — группы пользователя и уровни доступа. Проиллюстрируем эту связь ER-диаграммой.
Каждая операция характеризуется названием, принадлежностью к модулю, описанием и привязкой (о ней позже). Они задаются один раз, обычно при установке модуля, и редактированию более не подлежат.

Заметка для любопытных: операции хранятся в таблице БД b_operation.

Для создания уровня доступа необходимо задать ему имя, выбрать модуль, который он описывает и дать права на выполнение необходимых операций в этом модуле. Один уровень доступа описывает операции только одного модуля! Дополнительно можно указать букву уровня доступа (символьный код) и описание. Традиционно в стандартных модулях БУС используются следующие символьные коды:

• D для полного запрета;
• R для чтения;
• W для записи;
• X для полного доступа.

Еще раз отмечу, что это не правило, а наблюдение. Обратите внимание, уровни доступа, отсортированные по своим символьным кодам, обозначают возрастание привилегий. Нередко можно увидеть в исходниках БУС проверку вида “Если уровень доступа >= R” (вот зачем алфавитный порядок).

Созданные и настроенные уровни доступа хранятся в таблице БД b_task и b_task_operation.

Остальные шаги должны быть известны большинству специалистов по работе с 1С-Битрикс УС: нужно поместить пользователя в нужную нам группу и этой группе задать нужный уровень доступа в нашем модуле.

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

Управление кешем — операция главного модуля (main). Букву для уровня создавать не будем. Теперь у нас есть уровень доступа к главному модулю “Чистильщик кеша”. Осталось закрепить уровень доступа за группой нужного пользователя и протестировать. Как видно на экране, ничего кроме кнопки сброса кеша у нашего пользователя нет. Теперь уже можно переходить к программированию.

API для работы с операциями и уровнями доступа

Чтобы ваш модуль при установке создал в системе нужные вам операции, необходимо внести следующие изменения в установщик вашего модуля (/bitrix/modules/<ваш модуль>/install/index.php):

• в методе DoInstall вызвать метод InstallTasks (ну и в DoUninstall не забыть про UnInstallTasks);
• переопределить открытый метод GetModuleTasks. Пример кода из модуля Инфоблоков ниже.

Ключ массива — более или менее читаемый код уровня доступа, в нем есть ключи LETTER для буквы уровня доступа, BINDING для привязки операций и OPERATIONS для перечисления операций, которые входят в данный уровень доступа. Чтобы привязать операцию именно к модулю и работать с ней в обычном режиме, требуется либо не указывать ключ BINDING, либо указать там module.

Установка модуля пройдет без проблем и Ваши уровни появятся в панели управления в общем списке. Только вот у них не будет названия и описания. Вернее, они будут, только в том же виде, в котором вы их объявили в методе: iblock_deny, iblock_read и т.д.

Перевод этих строк происходит в файлах модуля /admin/task_description.php (для перевода уровней доступа) и /admin/operation_description.php (для перевода операций).

Содержимое файлов простое, по сути они должны возвращать данные следующего вида:
Ключи массива соответствуют ключам уровней и операций, а сами массивы содержат название и описание.

Эти файлы подключаются автоматически и не требуют дополнительных хлопот.

Осталось только использовать эти права по назначению — организовать в модуле их проверку. Для этого есть системный булевый метод CUser::CanDoOperation. Чтобы получить все уровни, которые есть у пользователя, используйте метод CUser::GetAllOperations. Проверка прав использует кеширование в сессии пользователя, так что можно себя не ограничивать и не бояться порождать лишние запросы.

Небольшой пример: попробуем организовать доступ на сайте по следующей матрице прав.
Матрица показывает, какие права есть у какого пользователя в некой компании. Выделено три роли: Глава компании, начальник отдела и рядовой сотрудник. Базовых операций 4 (так же известны как CRUD — Create-Read-Update-Delete), но есть нюансы — например, просмотр доступен в двух вариантах, изменение тоже, часто учитывается принадлежность сотрудников к отделам.

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

После анализа матрицы все выделенные операции объявляются в методе модуля GetModuleTasks.
После добавления языковых файлов и установки модуля все готово к воссозданию матрицы прав. Вот так выглядит уровень доступа “Начальник отдела”. А так — “Глава компании”.
Осталось лишь в коде поставить нужные проверки методом CanDoOperation.

Привязки (BINDING)

Напоследок, вернемся к привязкам. Они не используются в совсем уж простых модулях — можно сказать, это продвинутый уровень.

Обратите внимание на права доступа из модуля Инфоблоков (пример кода в предыдущем разделе). У каждого уровня привязка не к модулю, а к объекту iblock. Как следствие, на странице списка уровней доступа системы (“Настройки->Пользователи->Уровни доступа”) модуль инфоблоков вообще не представлен. Но любой достаточно оптыный специалист скажет, что где-то он уже видел настройку прав доступа для инфоблоков. Но где же?

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

Получается, что стандартные уровни доступа (с привязкой к модулю) редактируются в стандартном разделе панели управления, а для работы с любыми другими объектами вам нужно создавать свои собственные разделы “админки”. Получается, в 1С-Битрикс УС есть не только продуманная и удобная система прав доступа, но и база для создания своей собственной.

Помощь и благодарности

Автор выражает благодарность Сергею Покоеву и Павлу Машанову. Именно наши разговоры об управлении доступом вдохновили меня на эту статью.