Перейти к содержимому
BXWiki

Права доступа целиком - уровни, режимы, наследование, проверки

Разбираем доступ на всех уровнях: группы и их максимум, режимы прав инфоблока, права на файлы и модули, проверки в коде и места, где проверок нет.

Механика

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

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

У инфоблока два режима прав. Простой раздаёт доступ на весь инфоблок целиком, расширенный позволяет назначать наборы прав на отдельные разделы и элементы.

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

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

Права на модуль - третья независимая система. Она решает, пустят ли сотрудника в раздел административной части, и не связана с правами на конкретные данные.

Магазин добавляет четвёртую: роли менеджеров заказов. Роль описывает, что сотрудник видит и меняет в заказах, и на права инфоблоков она не влияет.

Кэш добавляет к этой картине задержку. Страница, собранная для одного набора групп, отдаётся из кэша и другому посетителю, если ключ кэша про группы ничего не знает.

Отсюда типовая путаница на проектах. «Права выданы, а доступа нет» почти всегда означает, что выданы права другой системы, а не той, что закрывает нужное действие.

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

Шаги

  1. Понять, какая система прав закрывает нужное действие: данные, файлы или модуль.
  2. Проверить, какие группы у сотрудника и какой максимум они дают вместе.
  3. Решить, нужен ли инфоблоку расширенный режим прав или хватает простого.
  4. Проверять право в своём коде до действия, а не полагаться на интерфейс.
  5. Знать места, где проверок прав нет вовсе, и закрывать их самим.

Код

Смотрим права сотрудника на модуль:

printf("iblock=%s catalog=%s sale=%s\n",
    $APPLICATION->GetGroupRight('iblock'),
    $APPLICATION->GetGroupRight('catalog'),
    $APPLICATION->GetGroupRight('sale'));
printf("группы: %s\n", implode(',', $USER->GetUserGroupArray()));
printf("администратор: %s\n", $USER->IsAdmin() ? 'да' : 'нет');
// уровень возвращается буквой: D - запрет, R - чтение, W - запись, X - полный
// под администратором проверки проходят всегда, и проверять доступ так нельзя

Права модуля отвечают только за административный раздел. Сотрудник с полным доступом к модулю инфоблоков всё равно не увидит данные, если на сам инфоблок права не выданы.

Смотрим режим прав инфоблока:

$mode = \CIBlock::GetArrayByID($iblockId, 'RIGHTS_MODE');
printf("режим прав: %s\n", $mode);      // S - простой, E - расширенный
print_r(\CIBlock::GetGroupPermissions($iblockId));   // группы и их уровни
// в расширенном режиме эта таблица пустеет: права живут наборами на разделах

Простой режим - это таблица «группа - уровень». Он покрывает почти все проекты, и переходить на расширенный стоит только тогда, когда разным разделам нужны разные редакторы.

Выдаём права в простом режиме:

\CIBlock::SetPermission($iblockId, [
    '1' => 'X',        // администраторы
    '7' => 'W',        // контент-менеджеры: правка элементов
    '2' => 'R',        // все посетители: только чтение
]);
// вызов заменяет таблицу прав целиком: передают полный набор групп

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

Проверяем право перед действием:

if (\CIBlockElement::GetPermission($elementId) < 'W') {
    throw new \RuntimeException('нет прав на изменение элемента');
}
if ($APPLICATION->GetGroupRight('vendor.module') < 'W') { return; }
// проверку делают до записи, а не после неё

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

Помним про обход проверок:

$rs = \CIBlockElement::GetList([], ['IBLOCK_ID' => $iblockId,
    'CHECK_PERMISSIONS' => 'N'], false, false, ['ID', 'NAME']);
// выборка вернёт всё, включая закрытые для этого сотрудника элементы

Отключение проверки прав в выборке - обычный приём служебных скриптов. В коде витрины он превращается в утечку: посетитель видит то, что закрыто настройками инфоблока.

Смотрим права на раздел сайта:

Окно терминала
cat /home/bitrix/www/upload/.access.php 2>/dev/null
grep -rl 'PERM' /home/bitrix/www/*/.access.php 2>/dev/null | head
find /home/bitrix/www -maxdepth 2 -name '.access.php' | head
# файл прав лежит в каталоге и действует на него вместе с вложенными
# вложенный каталог со своим файлом перекрывает права родителя

Отдельная привычка полезной команды - записывать выданные права. Таблица «группа, что видит, что меняет» в описании проекта экономит часы на каждом новом сотруднике и при каждой передаче проекта.

Ограничения

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

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

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

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

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

Типичные проблемы

Права выданы, а сотрудник по-прежнему без доступа.

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

Запрет в одной группе не срабатывает.

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

Скрипт выдачи прав отобрал доступ у остальных групп.

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

На витрине видны закрытые элементы.

В выборке отключена проверка прав, как это делают в служебных скриптах. В коде витрины проверку прав не отключают никогда.

Права проверены в шаблоне, а данные всё равно меняются.

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

После включения расширенного режима каталог замедлился.

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

Частые вопросы

Что означают буквы уровней доступа?

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

Когда нужен расширенный режим прав инфоблока?

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

Почему администратор видит всё?

Учётная запись администратора проходит проверки прав по определению. Поэтому доступ проверяют под обычным сотрудником с его настоящими группами.

Права на файлы и права на инфоблок - это одно и то же?

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

Как ограничить менеджера только своими заказами?

Ролями менеджеров магазина, а не правами инфоблоков. Это отдельная система, и настраивается она в разделе продаж.

Смежное

Первоисточник