Ограничение доступа на уровне записей (Record Level Security, или RLS) — один из самых мощных, но в то же время сложных для освоения механизмов платформы «1С:Предприятие». Из-за того, что ограничения накладываются неявно на уровне СУБД, разработчики часто сталкиваются с трудностями при поиске логических ошибок доступа и узких мест, влияющих на производительность. В этой статье мы подробно разберем, как укротить технологию RLS, какие инструменты использовать для ее отладки и как локализовать даже самые неочевидные проблемы доступа.
В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) версии 3.0 и выше используется новый, так называемый производительный (или универсальный) режим RLS. В отличие от старого режима, где ограничения рассчитывались динамически «на лету» для каждого запроса с помощью сложных шаблонов, новый режим работает по принципу кэширования прав.
Разберем по шагам, как устроена эта архитектура и как ее отлаживать:
КлючиДоступаКОбъектам, КлючиДоступаПользователей, ТаблицыГруппДоступа и другие. Шаблон RLS в ролях конфигурации при этом становится максимально простым и статичным — он сводится к конструкции вида #ДляОбъекта.
// Принудительное обновление ключей доступа для конкретного объекта
СсылкаНаОбъект = Справочники.Контрагенты.НайтиПоРеквизиту("ИНН", "7701020304");
УправлениеДоступомСлужебный.ОбновитьКлючиДоступа(СсылкаНаОбъект);
Поставив точку останова внутри процедуры ОбновитьКлючиДоступа модуля УправлениеДоступомСлужебный, мы сможем по шагам проследить, какие группы доступа и пользователи сопоставляются данному объекту и на каком этапе логика расчета дает сбой. Для точечной актуализации прав конкретного пользователя или группы пригодится инструмент для пересчета прав доступа.
В составе БСП поставляется специализированная обработка УправлениеДоступом.epf (ее также можно найти в составе дистрибутива БСП или на ИТС). Этот инструмент является незаменимым помощником для любого разработчика, работающего с правами доступа.
Рассмотрим возможности этой обработки подробнее:
Когда стандартных средств БСП недостаточно, на помощь приходит мощнейший сторонний комплекс — «Инструменты разработчика» (широко известный в сообществе 1С). В его составе есть специализированный Редактор ограничения доступа.
Этот инструмент позволяет:
Часто при записи или чтении объекта пользователь получает лаконичное сообщение: «Недостаточно прав для исполнения операции над базой данных». Журнал регистрации при этом фиксирует только факт нарушения прав, но не дает понимания, какая именно таблица или условие вызвали ошибку. Для решения этой задачи настроим сбор Технологического журнала (ТЖ).
Создадим или отредактируем файл конфигурации ТЖ logcfg.xml, добавив в него отслеживание событий выполнения запросов к СУБД и исключительных ситуаций:
<?xml version="1.0" encoding="UTF-8"?>
<logconfig xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs\rls_debug" keep="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<like property="Sql" value="%SDBL_DUMMY%"/>
</event>
<event>
<eq property="Name" value="DBPOSTGRS"/>
<like property="Sql" value="%SDBL_DUMMY%"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</logconfig>
Проанализируем структуру этого файла конфигурации. Мы фильтруем события выполнения SQL-запросов (DBMSSQL для MS SQL Server или DBPOSTGRS для PostgreSQL) по наличию ключевого маркера SDBL_DUMMY (или SDBL_DUAL). Платформа «1С:Предприятие» при трансляции запросов с ограничениями RLS на уровень СУБД всегда внедряет эти специфические конструкции. Это позволяет нам выделить «чистый» RLS-запрос из огромного потока других СУБД-событий.
При анализе логов ТЖ обратим внимание на цепочку событий перед отменой транзакции (ROLLBACK). Непосредственно перед событием отката будет идти тяжелый SQL-запрос, содержащий проверку прав, а следом за ним — событие EXCP (исключение), указывающее на конкретную таблицу метаданных, к которой у пользователя не хватило прав доступа.
Если ошибка синтаксическая или логическая, а специализированных инструментов под рукой нет, применим классический метод ручной отладки. Разработчики называют его «методом деления до размеров ума».
Выясним причину ошибки по шагам:
#Если &ДоступноОграничениеПоОрганизациям #Тогда).--) отдельные блоки условий ГДЕ или соединения (JOIN) с таблицами прав.Рассмотрим простейший пример секционирования шаблона:
// Исходный шаблон RLS:
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ГДЕ ТекущаяТаблица.Организация В (&РазрешенныеОрганизации)
И ТекущаяТаблица.Подразделение В (&РазрешенныеПодразделения)
// Для отладки в консоли проверяем части по отдельности:
// Шаг 1: Проверяем только организации
ВЫБРАТЬ * ИЗ Справочник.Организации КАК ТекущаяТаблица
ГДЕ ТекущаяТаблица.Ссылка В (&МассивТестовыхОрганизаций)
// Шаг 2: Проверяем только подразделения
ВЫБРАТЬ * ИЗ Справочник.ПодразделенияОрганизаций КАК ТекущаяТаблица
ГДЕ ТекущаяТаблица.Ссылка В (&МассивТестовыхПодразделений)
Проверить работу запроса с ключевым словом РАЗРЕШЕННЫЕ под административными правами невозможно, так как платформа игнорирует ограничения RLS для пользователей с полными правами. Чтобы не тратить время на постоянный перезапуск сеансов под разными пользователями, используем продвинутые консоли запросов.
Такие консоли инициализируют выполнение запроса через COM-соединение или фоновое задание от имени выбранного пользователя с ограниченными правами. Это позволяет оперативно вносить изменения в RLS-шаблоны в конфигураторе, обновлять конфигурацию базы данных и сразу же в один клик перевыполнять запрос в консоли, наблюдая за изменением состава результирующей выборки. Для проверки работы запросов под учетной записью с ограниченными правами можно использовать расширение для отладки запросов под пользователем.