← На главную

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

Анализ проблемы: почему RLS работает «на запись», но игнорирует «чтение»?

Рассмотрим типичную ситуацию: в самописной конфигурации на БСП добавлен справочник. Заказчик требует изолировать данные так, чтобы пользователь видел только те записи, которые относятся к определенному значению перечисления. Разработчик создает роль, прописывает шаблон ограничения на Чтение, Добавление и Изменение. Однако на практике происходит странное: система не дает создать «чужую» запись, но в списке справочника по-прежнему видны абсолютно все элементы.

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

Выясним основные «ловушки», которые мешают работе RLS:

1. Наличие роли «Полные права»: Эта роль по умолчанию дает доступ ко всем данным без учета RLS. Даже если вы добавите пользователю еще десять ролей с жесткими ограничениями, наличие полных прав их нивелирует.
2. Роли БСП для просмотра: В составе БСП есть предопределенные роли (например, ЧтениеБазовойНСИ или ПросмотрЖурналаРегистрации), которые могут косвенно или явно давать права на справочники.
3. Путаница между «Чтением» и «Просмотром»: Ограничение RLS устанавливается на право Чтение. Право Просмотр является визуальным интерфейсным правом. Если Чтение разрешено (пусть даже с RLS), а Просмотр запрещен — пользователь не увидит объект в интерфейсе вообще. Если же Просмотр разрешен в одной роли без ограничений (а он всегда без RLS), а Чтение разрешено в другой роли без ограничений — RLS не сработает.

Механизм работы ручного RLS в среде БСП

БСП спроектирована таким образом, чтобы автоматизировать управление доступом через Группы доступа и Профили. Однако платформа 1С позволяет использовать стандартные механизмы RLS параллельно. Рассмотрим, как это реализовать по шагам.

Шаг 1. Проверка состава ролей пользователя.
Первым делом проанализируем, какие роли назначены пользователю. В конфигурациях на БСП роли часто назначаются динамически при запуске системы. Проверим, нет ли у пользователя прав, которые «перекрывают» наш RLS. Важно помнить, что право на просмотр в платформе 1С не имеет поля для ввода текста ограничения, но оно неразрывно связано с правом на чтение. Если вы разрешили Просмотр в роли, где Чтение разрешено без RLS, ограничение не применится.

Шаг 2. Написание текста ограничения.
Предположим, нам нужно ограничить справочник Контрагенты по реквизиту ТипКонтрагента (Перечисление). В роли на право Чтение мы должны прописать запрос:

ГДЕ ТипКонтрагента = ЗНАЧЕНИЕ(Перечисление.ТипыКонтрагентов.ФизическоеЛицо)

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

Использование расширений для внедрения RLS

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

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

Оптимизация RLS: Производительный режим (RLS версии 2)

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

Разберем отличия:

• Старый режим: Запрос RLS выполняется как подзапрос к каждой таблице в основном запросе. При большом количестве соединений это вызывает существенные тормоза.
• Производительный режим: Система строит временные таблицы с разрешенными ключами доступа. БСП последних версий полностью ориентирована на этот механизм.

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

Типичные ошибки и методы их отладки

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

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

Для отладки запросов с учетом ограничений прав доступа крайне полезно использовать Консоль запросов. В современных консолях есть флаг «Выполнить с ограничением прав доступа». Посмотрим, как это работает: запустите консоль под пользователем с ограниченными правами, вставьте ваш запрос и посмотрите, какие данные вернутся. Если данных больше, чем нужно — значит, какая-то из ролей дает лишние права.

Заключение

Добавлять свои RLS в конфигурации на БСП можно и нужно, если типовые механизмы (группы доступа по значениям) кажутся избыточными для простой задачи. Главное — строго следить за тем, чтобы ни одна другая роль пользователя не давала право на чтение этого же объекта без ограничений. Помните, что «Полные права» — это главный враг тестирования RLS. Всегда проверяйте работу ограничений на специально созданном тестовом пользователе с минимальным набором ролей.