Разработка и Конфигурация · 11 мин
Что значит ВЫБРАТЬ РАЗРЕШЕННЫЕ в запросах 1С
Что означает ВЫБРАТЬ РАЗРЕШЕННЫЕ в запросах 1С, как работает отбор с учётом RLS, когда конструкцию использовать, а когда она замедляет запрос и даёт лишние строки.
Конструкция ВЫБРАТЬ РАЗРЕШЕННЫЕ в языке запросов 1С указывает платформе вернуть только те записи, на чтение которых у текущего пользователя есть права. Если у пользователя включены ограничения доступа на уровне записей (RLS) или нет прав на часть объектов, запрос без ключевого слова РАЗРЕШЕННЫЕ завершится ошибкой нарушения прав доступа, а с ним — отработает и вернёт лишь доступные данные.
Механизм работает так: платформа дополняет ваш запрос условиями из шаблонов ограничений доступа, заданных в ролях конфигурации, и фактически выполняет соединение с этими условиями на уровне СУБД. Поэтому РАЗРЕШЕННЫЕ — это не фильтр «на всякий случай», а инструмент, который меняет и результат, и план выполнения запроса.
Выбирать разрешённые записи нужно осознанно: в одних сценариях без этого слова запрос вообще не выполнится, в других оно замедляет выборку в разы или, наоборот, возвращает дубликаты строк. Ниже разобраны оба случая, порядок проверки и типичные ошибки.
Как работает РАЗРЕШЕННЫЕ на уровне платформы
Когда в тексте запроса указано ВЫБРАТЬ РАЗРЕШЕННЫЕ, платформа при компоновке итогового SQL подставляет условия из шаблонов ограничений доступа, которые описаны в ролях пользователя для соответствующих таблиц. Например, если в роли задан шаблон «Организация В (&ТекущаяОрганизация)», к выборке документов добавится условие по организации.
Если у пользователя нет ни одного шаблона RLS и есть полные права на объект, конструкция РАЗРЕШЕННЫЕ не добавляет условий, но и не даёт выигрыша — запрос выполняется как обычный. Если же RLS настроен, итоговый запрос становится сложнее: появляются дополнительные соединения и вложенные выборки, что напрямую влияет на время выполнения.
Важно понимать: РАЗРЕШЕННЫЕ работает только на чтение. Оно не защищает от изменения данных в обход прав — для этого существуют проверки прав при записи и механизм привилегированного режима.
Когда РАЗРЕШЕННЫЕ обязательно, а когда вредно
Ключевое слово необходимо, если запрос выполняется под пользователем, у которого есть ограничения по RLS, и при этом вы обращаетесь к таблице, на которую эти ограничения назначены. Без РАЗРЕШЕННЫЕ платформа выбросит исключение «Нарушение прав доступа» при попытке прочитать недоступные записи.
Конструкция вредна в двух ситуациях. Первая — код работает в привилегированном режиме или под пользователем с полными правами: проверка RLS не нужна, а платформа всё равно строит более тяжёлый план запроса. Вторая — запрос к регистрам сведений и накопления с большими шаблонами: соединение с шаблоном ограничения может увеличить время выполнения в разы.
Как выбрать действие
Синтаксис и примеры запросов
Ключевое слово ставится сразу после ВЫБРАТЬ, до перечисления полей. Оно может сочетаться с ПЕРВЫЕ, но не сочетается с РАЗЛИЧНЫЕ в одном запросе — это ограничение языка запросов, о котором часто забывают.
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Документы.Ссылка,
Документы.Организация,
Документы.СуммаДокумента
ИЗ
Документ.РеализацияТоваровУслуг КАК Документы
ГДЕ
Документы.Дата МЕЖДУ &НачалоПериода И &КонецПериода
Если в запросе несколько таблиц через соединение, РАЗРЕШЕННЫЕ применяется ко всем источникам выборки. Учтите: ограничение накладывается на каждую таблицу отдельно, поэтому соединение справочника с документом при RLS на обе таблицы даст двойную порцию условий в итоговом SQL.
Влияние на производительность и как его снизить
Главная цена РАЗРЕШЕННЫЕ — дополнительные соединения с таблицами, участвующими в шаблонах ограничений. Если шаблон обращается к регистру сведений с параметрами доступа (например, «ЗначенияГруппДоступа»), запрос обрастает вложенными выборками, и время выполнения растёт нелинейно с объёмом данных.
Снизить нагрузку можно несколькими способами. Во-первых, сначала отберите данные обычными условиями (период, организация, проведённые документы), а проверку прав оставьте платформе — чем меньше строк доходит до этапа проверки RLS, тем быстрее. Во-вторых, упростите сами шаблоны ограничений: один шаблон на несколько ролей лучше, чем пять разных. В-третьих, для пакетных операций переведите код в привилегированный режим и уберите РАЗРЕШЕННЫЕ.
- 1Выполните запрос под тестовым пользователем с реальной ролью, а не под администратором
- 2Убедитесь, что запрос не падает с ошибкой «Нарушение прав доступа»
- 3Сверьте количество возвращённых строк с ожидаемым набором доступных записей
- 4Замерьте время выполнения через замер производительности или консоль запросов
- 5Сравните план запроса с версией без РАЗРЕШЕННЫЕ и оцените добавленные соединения
- 6Если время неприемлемо — упростите шаблон RLS или перенесите выборку в привилегированный режим
Типичные ошибки при использовании
Самая частая ошибка — механическое добавление РАЗРЕШЕННЫЕ во все запросы «для безопасности». В привилегированном режиме это не даёт ничего, кроме лишнего синтаксического шума и потенциального замедления, а разработчик при этом думает, что данные как-то дополнительно защищены.
Вторая ошибка — ожидание, что РАЗРЕШЕННЫЕ уберёт дубликаты. Если соединение с шаблоном ограничения возвращает несколько строк на одну запись (например, пользователь входит в несколько групп доступа), вы можете получить задвоение строк результата. Проблему решают группировкой или корректной настройкой групп доступа, а не добавлением РАЗЛИЧНЫЕ — оно с РАЗРЕШЕННЫЕ несовместимо.
Третья ошибка — использование РАЗРЕШЕННЫЕ как единственной защиты при выгрузке данных. Если результат запроса потом обрабатывается в привилегированном режиме и выгружается наружу, проверка прав на этапе выборки уже не гарантирует корректность всей цепочки.
Как проверить, что запрос работает правильно
Проверять нужно под учётной записью с теми же ролями, что у целевых пользователей. Создайте тестового пользователя, назначьте ему ограниченную роль и выполните запрос в консоли запросов или через отладчик. Сравните результат с эталоном: пользователь должен видеть ровно те документы и справочники, которые доступны ему в интерфейсе.
Дополнительно полезно сравнить результат запроса с РАЗРЕШЕННЫЕ и без него под полными правами: если количество строк совпадает, значит, RLS для этого пользователя фактически не настроен, и стоит проверить роли.
Как проверить результат
Запрос отрабатывает без ошибок и возвращает только доступные записи
Ошибка «Нарушение прав доступа» или пустой результат при наличии доступных данных
Совпадает с числом записей, видимых пользователю в списках
Строк больше (дубли от групп доступа) или меньше (слишком жёсткий шаблон)
Сопоставимо с аналогичным запросом без РАЗРЕШЕННЫЕ
Рост времени в разы — нужно упрощать шаблон или пересматривать подход
Добавленные соединения используют индексы
Полные сканирования таблиц шаблонов ограничений
Альтернативы и смежные механизмы
РАЗРЕШЕННЫЕ — не единственный способ контролировать доступ к данным. В типовых конфигурациях широко применяется механизм групп доступа из БСП, который как раз реализуется через шаблоны RLS и автоматически учитывается конструкцией РАЗРЕШЕННЫЕ. Для отчётов на СКД ограничения применяются на уровне набора данных, если в запросе указано РАЗРЕШЕННЫЕ.
Альтернативный подход — явная фильтрация в коде: запрос без РАЗРЕШЕННЫЕ в привилегированном режиме с последующей программной проверкой через функциональные опции или параметры сеанса. Он оправдан в высоконагруженных выборках, где стоимость RLS-соединений неприемлема, но требует аккуратности: вся ответственность за корректность фильтра ложится на разработчика.
Сравнение вариантов
Просто и надёжно, права контролирует платформа; минус — замедление при сложных шаблонах RLS
Максимальная скорость и гибкость; минус — вся логика прав на разработчике, высок риск ошибки
Готовая настройка через интерфейс без кода; минус — работает только в связке с РАЗРЕШЕННЫЕ и шаблонами
Быстрые запросы; минус — пользователь видит всю таблицу целиком, подходит не всем
FAQ
Чем РАЗРЕШЕННЫЕ отличается от РАЗЛИЧНЫЕ?
РАЗЛИЧНЫЕ убирает дубли строк из результата, а РАЗРЕШЕННЫЕ фильтрует записи по правам пользователя. Это разные механизмы, и в одном запросе они несовместимы — платформа не даст скомпилировать такой текст.
Почему запрос с РАЗРЕШЕННЫЕ возвращает дубли строк?
Если шаблон ограничения соединяется с таблицей групп доступа, а пользователь входит в несколько групп, на одну запись может прийтись несколько строк результата. Решение — группировка итоговой выборки или пересмотр состава групп доступа пользователя.
Нужно ли РАЗРЕШЕННЫЕ в запросах регламентных заданий?
Как правило, нет. Регламентные задания обычно выполняются от имени служебного пользователя с полными правами или в привилегированном режиме, где проверка RLS не работает. Конструкция лишь замедлит выполнение.
Работает ли РАЗРЕШЕННЫЕ в динамических списках?
Да, и там оно особенно важно: динамический список выполняется под правами текущего пользователя, поэтому в произвольном запросе списка РАЗРЕШЕННЫЕ нужно указывать, иначе пользователи с ограниченными ролями получат ошибку при открытии формы.
Можно ли применить РАЗРЕШЕННЫЕ только к одной таблице в соединении?
Нет, ключевое слово относится ко всему оператору ВЫБРАТЬ и применяется ко всем источникам. Если ограничение нужно только для части данных, разбейте запрос на пакет из временных таблиц: сначала выберите разрешённые записи во временную таблицу, затем соединяйте её с остальными данными.
Как понять, что запрос тормозит именно из-за RLS?
Выполните тот же запрос без РАЗРЕШЕННЫЕ под полными правами и сравните время. Если разница кратная, посмотрите план запроса на СУБД: характерный признак — дополнительные соединения с таблицами групп доступа и вложенные подзапросы из шаблонов ограничений.
Что важно запомнить
ВЫБРАТЬ РАЗРЕШЕННЫЕ фильтрует результат запроса по правам пользователя с учётом RLS. Используйте его под пользователями с ограниченными ролями и в динамических списках, убирайте в привилегированном режиме, не сочетайте с РАЗЛИЧНЫЕ и всегда проверяйте скорость и состав результата под тестовой учётной записью с реальными правами.