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

Анатолий Ерофеев

Предисловие

В декабре 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. Пример кода из модуля Инфоблоков ниже.
API для настройки доступов Ключ массива — более или менее читаемый код уровня доступа, в нем есть ключи 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.
модуль GetModuleTasks После добавления языковых файлов и установки модуля все готово к воссозданию матрицы прав. Вот так выглядит уровень доступа “Начальник отдела”. Установка прав управления А так — “Глава компании”.
Права управления Осталось лишь в коде поставить нужные проверки методом CanDoOperation.

Привязки (BINDING)

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

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

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

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

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

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

Статьи по теме

07.03.2023
Дорожная карта внедрения платформы автоматизации оптовых продаж Про построение эффективных отделов продаж написано много крутых статей. Одни эксперты готовы сделать это за 10 шагов, другие предлагают многоэтапную эволюц...
16.02.2023
Как начать B2B-продажи онлайн - особенности и методы оптовой торговли После пандемии рынок e-commerce начал стремительно расти. Мы говорим не только о B2C, но и о B2B-сегменте. Многие крупные компании уже разглядели потенциал...
10.01.2023
Как битриксоиды в React уходили Приятно познакомиться, мы битриксоиды. Да-да, те самые которые: вообще не модные, пишут НЕ на Laravel и Symfony, ...
10.01.2023
Товарная дистрибуция 30 лет спустя. Как программисты изменили продажи крупного бизнеса «Я думал, что буду строить банк, а на самом деле построил ИТ-компанию» Олег Тиньков, безработный Есть такая штука — товарная дистри...
10.01.2023
Как мы решили выпускать собственный продукт через CustDev и у нас получилось Собственный продукт как фиксация компетенции&nbsp; В развитии крупных компаний-аутсорсеров наступает момент, когда они уже обросли опытом и компетенциями ...
19.12.2022
Учимся настраивать свою почту, не наступая на чужие грабли: Postfix + msmtp + сайт Привет, меня зовут Никита, я backend-разработчик в компании ИНТЕРВОЛГА. Работаю в компании уже 3 года, и за этот срок достаточно часто мне приходилось вози...

Мы работаем по одному из двух форматов:

  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).

ИНТЕРВОЛГА предоставляет:

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

Для доработок и развития мы предлагаем формат 100 часов в месяц. Что можно сделать за это время:

  • новые нетиповые страницы или раздел;
  • 2 отчета с индивидуальными настройками;
  • 3-5 веб-сервисов интеграции;
  • замудренный калькулятор и т.п.

Поддержка «чтобы все работало как часы» стоит 45 тысяч рублей в месяц и описана тут.

Хочешь получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишись на рассылку — спамить не будем