Почему после включения RLS возникают ошибки «Отказ в доступе» и как протестировать конфигурацию?

← На главную

Внедрение механизма ограничения прав на уровне записей (RLS) на ключевые объекты метаданных — частая задача при разграничении доступа. Однако после включения ограничений пользователи нередко сталкиваются с ошибками вида Доступ. Отказ в доступе при выполнении привычных операций: проведении документов, открытии списков или формировании отчетов. Разберем по шагам, где именно спотыкается платформа при работе с RLS, как исправить программный код и как организовать автоматизированное тестирование форм и сценариев.

Основные причины падения RLS в коде и запросах

Проанализируем типовые ситуации, из-за которых в непривилегированном коде возникает системное исключение нарушения прав:

Отсутствие ключевого слова РАЗРЕШЕННЫЕ в запросах. Если запрос обращается к таблице документа или регистра, на которую наложен RLS, без модификатора РАЗРЕШЕННЫЕ, СУБД пытается прочитать все строки. Встретив хотя бы одну недоступную запись, платформа выбрасывает исключение отказа в доступе.
Разыменование ссылок через точку в запросах. Конструкции вида Таблица.СсылкаНаДокумент.Реквизит неявно преобразуются платформой в левое соединение с таблицей документа. Если к этому документу применен RLS, на соединение накладываются условия ограничения, что приводит к ошибкам или неожиданной потере строк даже при наличии РАЗРЕШЕННЫЕ.
Прямое обращение к реквизитам через точку в программном коде. Вызов Ссылка.Реквизит или метод Ссылка.ПолучитьОбъект() инициируют полное чтение объекта из базы данных. Если у текущего сеанса нет прав на чтение конкретной записи, платформа прерывает выполнение с ошибкой доступа.
Пакетные запросы и временные таблицы. Ключевое слово РАЗРЕШЕННЫЕ действует исключительно на тот запрос из пакета, в котором оно явно прописано. Если выборка во временную таблицу оформлена без этого слова, весь пакет завершится аварийно.
Запись движений при проведении. При записи наборов записей регистров платформа неявно проверяет права на регистратор. Если у пользователя ограничены права на документ-регистратор, запись набора завершится отказом в доступе.

Способ 1. Корректировка текстов запросов и безопасное чтение данных

Рассмотрим, как правильно доработать проблемные участки кода. В первую очередь проверяем все обращения к данным через запросы. Обязательно указываем директиву РАЗРЕШЕННЫЕ во всех выборках пакета:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ РАЗРЕШЕННЫЕ
    |	ЗаказКлиента.Ссылка КАК Ссылка,
    |	ЗаказКлиента.СуммаДокумента КАК СуммаДокумента
    |ИЗ
    |	Документ.ЗаказКлиента КАК ЗаказКлиента
    |ГДЕ
    |	ЗаказКлиента.Проведен = ИСТИНА";
РезультатЗапроса = Запрос.Выполнить();

Для чтения реквизитов объектов на клиенте или сервере без риска получить блокировку RLS и без полной загрузки объекта в память используем функции БСП:


// Безопасное получение значения одного или нескольких реквизитов
ЗначениеРеквизита = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СсылкаНаОбъект, "Организация");

Способ 2. Использование привилегированного режима для служебных операций

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

Разберем пример программного переключения режима:


УстановитьПривилегированныйРежим(Истина);
Попытка
    // Выполнение служебной выборки данных или записи наборов
    ЗаписатьСлужебныеДвижения(Параметры);
    УстановитьПривилегированныйРежим(Ложь);
Исключение
    УстановитьПривилегированныйРежим(Ложь);
    ВызватьИсключение;
КонецПопытки;

Важно: логику проведения документов и расчет проводок рекомендуется выносить в общие серверные модули с установленным флажком Привилегированный.

Способ 3. Проверка ключей доступа при использовании БСП

Если в конфигурации используется современный механизм «Производительного RLS» библиотеки стандартных подсистем (на ключах доступа), ошибки доступа часто возникают из-за нерассчитанных прав. Проанализируем обязательные шаги настройки:

В модуле менеджера нового документа переопределяем процедуру ПриЗаполненииКлючейДоступа(), описав правила формирования ключей по полям (например, организация, подразделение, группа доступа).
После внедрения изменений запускаем регламентное задание Обновление доступа на уровне записей либо вручную инициируем пересчет ключей для обновленного метаданного, иначе все существующие документы останутся заблокированными для чтения.

Автоматизированное тестирование и диагностика ошибок RLS

Выясним, какие инструменты подходят для тестирования работоспособности конфигурации после внедрения RLS:

АПК (Автоматизированная проверка конфигураций) — выполняет статический анализ исходного кода на соответствие стандартам разработки 1С и требованиям «1С:Совместимо». АПК не проверяет динамическую работоспособность программы в рантайме под конкретным пользователем.
Дымовые тесты (Smoke tests) через xUnitFor1C — специализированные автоматические тесты, которые запускаются под сеансом пользователя с ограниченными правами. Фреймворк выполняет открытие всех форм списков, форм документов и отчетов. Если при открытии динамического списка или инициализации формы возникает ошибка RLS, тест сразу фиксирует сбой.
Сценарное тестирование — фирменный инструмент 1С для прогона сложных пользовательских сценариев (создание, проведение, ввод на основании, печать) под разными ролями.
Журнал регистрации и Технологический журнал — при локализации единичных падений фильтруем события журнала регистрации по событию Доступ. Отказ в доступе, где платформа указывает точный метаданный и контекст ошибки.