Как применить RLS в веб-сервисе 1С для внешнего пользователя?

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

Понимание ограничений платформы

Важно помнить, что механизм РАЗРЕШЕННЫЕ в запросах 1С работает только в контексте прав текущего сеанса пользователя. Если веб-сервис выполняется под техническим пользователем (с полными правами), то РАЗРЕШЕННЫЕ не отсечет ничего лишнего, так как у технического пользователя доступ есть ко всему. Кроме того, использование привилегированного режима полностью отключает проверку RLS, что делает запрос «прозрачным» для всех ограничений.

Способ 1: Подмена параметров сеанса

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

Рассмотрим логику реализации:

1. При поступлении запроса от мобильного приложения получаем идентификатор пользователя или его настройки доступа.
2. В процедуре обработки запроса принудительно устанавливаем ПараметрыСеанса, от которых зависят ваши шаблоны ограничений доступа.
3. Выполняем запрос с использованием конструкции ВЫБРАТЬ РАЗРЕШЕННЫЕ.

Важно: Этот способ работает только в том случае, если RLS настроен на использование параметров сеанса, а не на функцию ТекущийПользователь(). Платформа 1С кэширует права доступа при старте сеанса, поэтому «переключение» пользователя в рамках одного сеанса может не сработать для встроенных проверок прав.

Способ 2: Использование дублирующих ролей

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

Способ 3: Программная фильтрация данных

Самый безопасный и предсказуемый способ с точки зрения производительности — это отказ от попыток «заставить» платформу применить RLS автоматически в пользу явной фильтрации. Рассмотрим, как это сделать:

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

Пример реализации фильтрации:

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

Почему не стоит создавать новый сеанс для каждого запроса?

Часто возникает соблазн авторизоваться в системе под тем пользователем, который запрашивает данные, через создание нового COM-соединения или инициализацию нового сеанса. Мы настоятельно рекомендуем избегать этого решения в продуктовых (production) HTTP-сервисах.

• Производительность: Создание сеанса 1С — это «дорогая» операция, требующая больших ресурсов сервера.
• Конкурентность: При высокой нагрузке пул сеансов быстро истощится, что приведет к зависанию веб-сервиса и всего сервера 1С.
• Безопасность: Управление COM-соединениями требует особой настройки прав на сервере, что создает дополнительные риски.

Заключение: какой путь выбрать?

Анализируя ситуацию, мы рекомендуем двигаться от простого к сложному:

1. Если архитектура системы позволяет, используйте программное формирование фильтров. Это дает полный контроль над производительностью запросов и не зависит от кэширования прав платформы.
2. Если требуется глобальное применение RLS, проверьте возможность использования ПараметровСеанса. Убедитесь, что ваши роли в конфигураторе используют их, а не функции контекста пользователя.
3. Избегайте создания отдельных сеансов для каждого веб-запроса, чтобы не превратить ваше решение в узкое место производительности системы.

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