Подробный гайд по отладке RLS в 1С:Предприятие 8.3 - Часть 1
1. Что такое RLS в контексте 1С
RLS, Row-Level Security, в 1С — это ограничение доступа на уровне записей. Пользователь может иметь право читать объект метаданных, но видеть не все записи, а только те, которые разрешены условием ограничения.
Примеры:
- менеджер видит только свои заказы;
- пользователь видит документы только по своей организации;
- кладовщик видит документы только по своему складу;
- руководитель видит документы подчиненных подразделений;
- внешний пользователь видит только свои заявки.
В 1С RLS может быть реализован через:
- Платформенные ограничения доступа на уровне записей в ролях.
- Механизмы БСП: виды доступа, группы доступа, профили групп доступа, значения доступа.
- Программные фильтры в запросах, формах, отчетах.
- Комбинацию всех перечисленных механизмов.
При отладке первое, что нужно сделать, — понять, какой именно слой ограничивает данные.
2. Типовые симптомы проблем с RLS
Проблемы обычно выглядят так:
2.1. Пользователь не видит часть записей
Например, в списке документов пусто или отсутствуют документы, которые пользователь должен видеть.
Возможные причины:
- неправильно заполнены параметры сеанса;
- условие RLS слишком жесткое;
- пользователь не входит в нужную группу доступа;
- в БСП не настроены значения доступа;
- запрос не использует ограничения прав доступа;
- запись не соответствует ни одному условию доступа.
2.2. Пользователь видит лишнее
Например, пользователь видит документы чужой организации или чужого склада.
Возможные причины:
- пользователю назначена роль с полными правами;
- одна из ролей дает неограниченное чтение;
- в БСП профиль доступа разрешает все объекты;
- запрос не применяет
РАЗРЕШЕННЫЕ; - отчет или обработка читают данные в привилегированном режиме;
- временные таблицы заполняются без учета прав.
2.3. Пользователь видит запись в списке, но не может открыть
Возможные причины:
- есть ограничение на чтение, но нет прав на просмотр или изменение;
- форма при открытии читает связанные данные, к которым нет доступа;
- отсутствует право на реквизит или связанную таблицу;
- ограничение срабатывает только на изменение, а не на чтение;
- открытие объекта выполняется через другой механизм доступа.
2.4. Пользователь не может записать документ
Возможные причины:
- нет прав на изменение или добавление;
- ограничение на уровне записей для операции изменения не разрешает запись;
- при записи читаются регистры или связанные объекты без прав;
- код модуля использует привилегированный режим некорректно;
- БСП запрещает изменение из-за настроек профиля или группы доступа.
2.5. Все работает медленно
RLS может сильно влиять на производительность.
Типовые причины:
- условие содержит большие списки значений;
- ограничение приводит к сложным соединениям;
- поля в условии не проиндексированы;
- условие не может быть эффективно передано в СУБД;
- используется много ролей или много параметров;
- БСП рассчитывает значения доступа динамически и тяжело.
3. Подготовка к отладке
3.1. Не отлаживайте сразу в продуктивной базе
Желательно подготовить копию базы или тестовый контур. Причины:
- RLS связан с безопасностью;
- можно случайно дать лишние права;
- можно неверно изменить роли или группы доступа;
- диагностика производительности может создать нагрузку.
Если отладка выполняется в продуктиве, действуйте особенно осторожно и только с правами администратора, без изменения реальных пользователей.
3.2. Создайте воспроизводимый сценарий
Для диагностики нужно иметь минимальный набор данных:
- Конкретный пользователь.
- Конкретная роль, профиль доступа или группа доступа.
- Конкретный объект метаданных: документ, справочник, регистр.
- Конкретная запись, которая должна быть видна.
- Конкретная запись, которая должна быть не видна.
- Операция: чтение, изменение, удаление, просмотр в форме, чтение через запрос.
Пример:
Пользователь manager1 должен видеть документ ЗаказКлиента с менеджером manager1, но не должен видеть документ с менеджером manager2. Если сценарий не воспроизводится точно, отладка превращается в поиск случайных совпадений.
3.3. Подготовьте тестового пользователя
Создайте отдельного пользователя, у которого только минимально необходимые роли.
Важно:
- не используйте администратора для проверки RLS;
- не назначайте тестовому пользователю роль с полными правами;
- проверьте, что пользователь действительно входит в нужные группы;
- если используется БСП, проверьте группы и профили доступа;
- если используется доменная аутентификация, проверьте соответствие пользователя ИБ и пользователя ОС.
Административные права часто приводят к тому, что ограничения не применяются или применяются иначе. Для проверки RLS нужен обычный пользователь.
3.4. Определите слой ограничения
Перед тем как лезть в роли, запросы и БСП, ответьте на вопрос:
- Где именно должна ограничиваться видимость?
Варианты:
- Платформенная роль с ограничением на уровне записей.
- БСП: виды доступа, группы доступа, значения доступа.
- Программный фильтр в запросе.
- Фильтр в форме списка.
- Фильтр в отчете СКД.
- Внешний сервис, веб-сервис или HTTP-сервис.
Если в конфигурации используется БСП, очень часто проблема не в платформенной роли, а в настройках групп доступа.
4. Проверка ролей и прав пользователя
4.1. Проверьте состав ролей пользователя
Откройте карточку пользователя и проверьте:
- активен ли пользователь;
- назначены ли роли;
- нет ли роли с полными правами;
- нет ли лишних ролей;
- не перекрывают ли роли друг друга.
Особенно важно:
Если у пользователя есть роль, дающая право чтения объекта без ограничений, она может привести к тому, что пользователь будет видеть больше, чем ожидалось. Для диагностики лучше всего временно оставить пользователю одну тестовую роль.
4.2. Проверьте права на объект
Для объекта метаданных у пользователя должны быть нужные права.
Например, для чтения документа обычно нужно право:
Чтение;- иногда также
Просмотр, если объект открывается в форме.
Для изменения:
Изменение;- иногда
Чтение,Просмотр,Редактированиев зависимости от механизма.
Для удаления:
Удаление.
Если у пользователя нет базового права на объект, RLS уже не имеет значения — объект будет недоступен полностью.
4.3. Проверьте, не слишком ли широкие права
Частая ошибка:
Разработчик создал роль с RLS, но пользователю также назначена типовая роль с полным доступом. В итоге пользователь видит все, потому что одна из ролей дает неограниченный доступ.
Проверьте:
- роли пользователя;
- профили групп доступа;
- группы пользователей;
- наследование ролей;
- расширения, если они добавляют роли.
4.4. Проверьте роли в расширениях
Если используются расширения:
- Проверьте, активно ли расширение.
- Проверьте, назначены ли роли из расширения.
- Проверьте, не переопределяют ли они основную конфигурацию.
- Проверьте безопасный режим расширения, если он используется.
- Убедитесь, что изменение конфигурации принято и опубликовано.
Иногда кажется, что роль изменена в основной конфигурации, но фактически применяется роль из расширения.
5. Проверка платформенных ограничений на уровне записей
5.1. Где искать ограничения
Обычно ограничения на уровне записей настраиваются в роли:
- открывается роль;
- выбирается объект метаданных;
- для операции чтения, изменения или удаления задается условие ограничения.
В зависимости от версии платформы и конфигурации это может называться:
- ограничения доступа на уровне записей;
- RLS;
- шаблоны ограничений;
- условия ограничения.
5.2. Проверьте, для какой операции задано ограничение
Ограничение может быть задано отдельно для разных операций.
Например:
- только для чтения;
- для чтения и изменения;
- для удаления;
- для добавления, если механизм это поддерживает.
Частая ошибка:
Ограничение настроено только для чтения, а проблема возникает при записи документа.
Или наоборот:
Пользователь видит документ в списке, но не может изменить, потому что ограничение на изменение другое или отсутствует нужное право.
5.3. Проверьте текст условия
Условие ограничения обычно похоже на выражение запроса.
Примеры:
Менеджер = &ТекущийМенеджер
Организация = &РазрешеннаяОрганизация
Склад В (&РазрешенныеСклады)
Подразделение В (&РазрешенныеПодразделения)
ИЛИ Автор = &ТекущийПользователь
Проверьте:
- Правильное имя реквизита.
- Правильный оператор:
=,В,НЕ В,И,ИЛИ,НЕ. - Правильные параметры сеанса.
- Корректность скобок.
- Нет ли опечаток.
- Не используется ли условие, которое всегда ложно.
- Не используется ли условие, которое всегда истинно.
5.4. Проверьте параметры сеанса
RLS очень часто использует параметры сеанса.
Например:
Организация = &МояОрганизация
Если параметр МояОрганизация не заполнен или заполнен неверно, пользователь не увидит нужные записи.
Проверьте:
- Существует ли параметр сеанса в конфигурации.
- Заполняется ли он при старте сеанса.
- Какой у него тип.
- Какое значение он получил для конкретного пользователя.
- Не пустое ли значение.
- Совпадает ли тип значения параметра с типом реквизита в условии.
6. Диагностика параметров сеанса
6.1. Где задаются параметры сеанса
Параметры сеанса обычно задаются в обработчике:
ПриОпределенииПараметровСеанса
Он может находиться в модуле управляемого приложения, модуле обычного приложения или в общем механизме конфигурации.
Пример:
Процедура ПриОпределенииПараметровСеанса(ПараметрыСеанса) Экспорт
ПараметрыСеанса.РазрешеннаяОрганизация = ПолучитьОрганизациюПользователя();
КонецПроцедуры
В типовых конфигурациях и БСП заполнение параметров может быть значительно сложнее.
Там могут использоваться:
- общие модули;
- подписки на события;
- справочники пользователей;
- значения доступа;
- регистры сведений;
- временные таблицы;
- кэширование.
6.2. Проверка значения параметра
Создайте серверную процедуру, которая запишет значение параметра в журнал регистрации.
Пример:
&НаСервере
Процедура Отладка_ЗаписатьПараметрыСеанса()
Текст = "Текущий пользователь ИБ: "
+ Строка(ПользователиИнформационнойБазы.ТекущийПользователь())
+ "; Параметр сеанса РазрешеннаяОрганизация: "
+ Строка(ПараметрыСеанса.РазрешеннаяОрганизация);
ЗаписьЖурналаРегистрации(
"ОтладкаRLS",
УровеньЖурналаРегистрации.Информация,
,
Текст
);
КонецПроцедуры
Вызовите ее из формы под исследуемым пользователем. Затем откройте журнал регистрации и посмотрите, какое значение параметра реально получил сеанс.
6.3. Проверка типа параметра
Если параметр должен быть ссылкой на справочник, проверьте тип.
Пример:
ЗначениеПараметра = ПараметрыСеанса.РазрешеннаяОрганизация;
Если ТипЗнч(ЗначениеПараметра) <> Тип("СправочникСсылка.Организации") Тогда
ЗаписьЖурналаРегистрации(
"ОтладкаRLS",
УровеньЖурналаРегистрации.Ошибка,
,
"Неверный тип параметра: " + Строка(ТипЗнч(ЗначениеПараметра))
);
КонецЕсли;
Частая ошибка:
Реквизит в документе имеет тип СправочникСсылка.Организации, а параметр сеанса заполнен строкой, числом или неопределенным значением. В результате условие либо не выполняется, либо работает не так, как ожидалось.
6.4. Пустые значения параметров
Если параметр пустой, условие вида:
Организация = &МояОрганизация
может не вернуть ни одной записи. Иногда это ожидаемое поведение. Иногда ошибка.
Проверьте:
- должен ли пользователь вообще иметь доступ, если параметр пуст;
- что считать пустым значением:
Неопределено, пустую ссылку, пустой массив; - нужно ли подставлять значение по умолчанию;
- нужно ли запрещать работу при пустом параметре.
6.5. Параметры сеанса и кэш
Параметры сеанса могут определяться при старте сеанса. Если вы изменили механизм заполнения параметров, но пользователь остался в старом сеансе, изменения могут не примениться.
Сделайте:
- Завершение сеанса пользователя.
- Повторный вход.
- При необходимости перезапуск рабочих процессов 1С.
- Очистку пользовательского кэша, если проблема связана с клиентским кэшированием.
7. Проверка через запросы
7.1. Используйте консоль запросов
- Если в конфигурации доступна консоль запросов, выполните тестовый запрос под проверяемым пользователем.
- Если консоли нет, создайте внешнюю обработку или форму с серверным вызовом.
7.2. Запрос с ключевым словом РАЗРЕШЕННЫЕ
Чтобы ограничения прав доступа применялись в запросе, обычно используется ключевое слово РАЗРЕШЕННЫЕ.
Пример:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
| Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ";
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Выборка.Следующий();
Сообщить("Количество доступных заказов: " + Выборка.Всего);
Важно: запрос должен выполняться под тем пользователем, для которого проверяется доступ, и без привилегированного режима.
7.3. Сравнение запроса с РАЗРЕШЕННЫЕ и без него
Для диагностики можно выполнить два запроса:
- С
РАЗРЕШЕННЫЕ. - Без
РАЗРЕШЕННЫЕ.
Пример:
ТекстСРазрешенными =
"ВЫБРАТЬ
| КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
| Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ";
ТекстБезРазрешенных =
"ВЫБРАТЬ
| КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
| Документ.ЗаказКлиента КАК Заказ";
Если первый запрос вернул меньше строк, чем второй, значит ограничения действительно применяются или должны применяться.
Но будьте осторожны:
- не выполняйте такие проверки в продуктивной базе под обычным пользователем, если не понимаете последствия;
- если у пользователя есть неограниченные права, разница может быть незаметна;
- в некоторых механизмах платформа может применять права иначе, чем в запросе вручную.
7.4. Проверка конкретной записи через ПравоДоступа
Для проверки доступа к конкретной записи можно использовать функцию ПравоДоступа.
Пример:
СсылкаНаДокумент = Документы.ЗаказКлиента.НайтиПоНомеру("0000001", );
Если ЗначениеЗаполнено(СсылкаНаДокумент) Тогда
Сообщить("Чтение: " + ПравоДоступа("Чтение", СсылкаНаДокумент));
Сообщить("Изменение: " + ПравоДоступа("Изменение", СсылкаНаДокумент));
КонецЕсли;
Это удобно, когда нужно быстро проверить одну запись. Если ПравоДоступа("Чтение", ...) возвращает Ложь, значит пользователь не имеет права читать эту запись с учетом текущих ограничений.
7.5. Проверка через временные таблицы
Частая ошибка:
Данные сначала выгружаются во временную таблицу без учета прав, а затем используются в отчете или форме. Если временная таблица заполнена без РАЗРЕШЕННЫЕ, пользователь может получить лишние данные.
Неправильная логика:
1. Выгрузить все документы во временную таблицу.
2. Показать пользователю временную таблицу.
Правильная логика:
1. Выгрузить только разрешенные документы.
2. Использовать их дальше.
В запросах с временными таблицами проверяйте источник данных, а не только итоговую выборку.
8. Проверка списков и форм
8.1. Динамические списки
Если проблема проявляется в списке документа, проверьте:
- Используется ли динамический список.
- Есть ли у списка собственные отборы.
- Есть ли пользовательские настройки, скрывающие записи.
- Применяются ли права доступа к источнику данных списка.
- Не установлен ли фильтр по организации, складу, пользователю.
- Нет ли программного фильтра в модуле формы.
Иногда кажется, что виноват RLS, а на самом деле в списке стоит пользовательский отбор.
8.2. Форма объекта
Если запись видна в списке, но не открывается в форме:
- Проверьте
ПравоДоступа("Чтение", Ссылка). - Проверьте права на просмотр.
- Проверьте права на изменение, если форма открывается в режиме редактирования.
- Проверьте, какие данные читает форма при открытии.
- Проверьте модуль формы: нет ли чтения связанных объектов без прав.
- Проверьте привилегированный режим.
Форма может читать:
- сам документ;
- реквизиты;
- табличную часть;
- движения;
- регистры;
- связанные справочники;
- настройки пользователя;
- права на изменение.
Если один из этих объектов недоступен, форма может не открыться или открыться с ошибкой.
8.3. Ошибки при открытии формы
Типовые сообщения могут быть похожи на:
- недостаточно прав;
- ошибка доступа;
- нарушение прав доступа;
- объект не найден;
- не удалось получить данные.
Если объект не найден, это не всегда означает, что его физически нет. Иногда система скрывает недоступные записи как несуществующие.
9. Проверка отчетов и СКД
9.1. Отчеты могут не учитывать RLS автоматически
Отчет на СКД может читать данные по-разному:
- Через запрос с
РАЗРЕШЕННЫЕ. - Через запрос без
РАЗРЕШЕННЫЕ. - Через временные таблицы.
- Через программную выгрузку.
- через веб-сервис или внешний источник.
Если отчет показывает лишнее, проверьте текст запроса набора данных.
9.2. Что проверять в отчете
Проверьте:
- есть ли в запросе
РАЗРЕШЕННЫЕ; - не отключен ли учет прав доступа в настройках набора данных;
- не выполняется ли отчет в привилегированном режиме;
- не используются ли временные таблицы без ограничений;
- не подменяются ли данные программно;
- не подключаются ли регистры, к которым у пользователя нет доступа.
9.3. Пример запроса отчета с учетом разрешений
ВЫБРАТЬ
Заказ.Дата КАК Дата,
Заказ.Номер КАК Номер,
Заказ.СуммаДокумента КАК Сумма
ИЗ
Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ
ГДЕ
Заказ.ПометкаУдаления = ЛОЖЬ
Если вместо этого в отчете написано:
ИЗ Документ.ЗаказКлиента КАК Заказ
то ограничения могут не применяться.
10. Особенности отладки в БСП
Во многих типовых конфигурациях используется библиотека стандартных подсистем.
Там доступ часто управляется через:
- пользователей;
- группы пользователей;
- группы доступа;
- профили групп доступа;
- виды доступа;
- значения доступа;
- настройки прав;
- параметры сеанса.
В таком случае недостаточно смотреть только платформенные роли.
10.1. Что проверить в БСП
Обычно нужно проверить:
- Пользователь включен в нужную группу пользователей или группу доступа.
- Для группы доступа назначен нужный профиль.
- Профиль не имеет флага полного доступа.
- В профиле настроены виды доступа.
- Для видов доступа заданы разрешенные значения.
- Значения доступа активны.
- Нет конфликтующих групп.
- Нет наследования более широких прав.
- Для объекта включен нужный вид доступа.
- Параметры сеанса заполняются по настройкам БСП.
10.2. Типовые места настройки
В зависимости от конфигурации это может находиться в разделах:
Администрирование;Настройки пользователя и права;Пользователи и права;Группы доступа;Профили групп доступа;Виды доступа;Значения доступа.
Названия могут отличаться, но смысл обычно одинаковый.
10.3. Типовая ошибка БСП
Пример:
- пользователь входит в группу
Менеджеры; - для группы настроен доступ только по организации
Организация 1; - но пользователь также входит в группу
Администраторыили профиль с полным доступом; - в результате пользователь видит все.
Или обратная ситуация:
- пользователю назначили вид доступа по складам;
- но забыли назначить конкретный склад;
- пользователь не видит ни одного склада.
10.4. Используйте стандартные отчеты по правам
Во многих конфигурациях есть отчеты или обработки вида:
- права доступа;
- настройки прав;
- группы доступа;
- полномочия пользователя;
- анализ прав доступа.
Они помогают быстро увидеть, какие значения доступа реально назначены пользователю.
Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.