При разработке интеграций и расширений для современных конфигураций 1С (таких как «Зарплата и Управление Персоналом», ERP, «Комплексная автоматизация») разработчики часто сталкиваются с неочевидным поведением системы прав доступа. Казалось бы, простая задача — получить данные сотрудника и отфильтровать их по дополнительному свойству через HTTP-сервис — может привести к критической ошибке выполнения запроса. Для более глубокого понимания контекста рекомендуем изучить HTTP-сервисы в 1С: практические советы и примеры, а если вы проектируете сложную систему, вам может быть полезна библиотека для создания API-шлюзов на платформе 1С.
Рассмотрим ситуацию, когда при выполнении запроса к ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения или регистру ДополнительныеСведения возникает ошибка ограничения доступа на уровне записей (RLS), связанная с неустановленным параметром сеанса ТекущийПользователь. Разберем детально причины этого сбоя и правильный алгоритм создания технических пользователей для веб-сервисов.
Представим сценарий: мы создали расширение с HTTP-сервисом. Сервис авторизуется под специальным техническим пользователем (например, с именем "web"). Код работает корректно, пока мы не пытаемся обратиться к механизму дополнительных свойств. Как только мы добавляем в запрос таблицу дополнительных сведений или пытаемся найти свойство по наименованию, платформа выдает ошибку, в которой проявляются особенности настройки RLS в типовых конфигурациях 1С:
Ошибка выполнения запроса по причине:
Ошибка в ограничении доступа к данным.
объект: 'ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения'; право: 'Чтение'
... Не удалось установить параметр сеанса ТекущийПользователь.
Пользователь "web" не существует в справочнике "Пользователи".
Также может возникать ошибка при вызове метода НайтиПоНаименованию:
Свойство = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("НеВыгружать", Истина);
// Вызывает исключение "Ошибка при вызове метода контекста"
Для детального разбора того, какие именно ограничения мешают работе, можно использовать инструмент для быстрой проверки прав доступа на объект метаданных, который покажет связи ролей и профилей. Даже использование УстановитьПривилегированныйРежим(Истина) часто не решает проблему, если ошибка происходит на этапе инициализации параметров сеанса или внутри шаблонов RLS, которые отрабатывают до того, как привилегированный режим вступит в силу. Подобные нюансы программной работы с правами доступа в 1С важно учитывать при проектировании внешних интерфейсов.
Современные типовые конфигурации построены на базе Библиотеки Стандартных Подсистем (БСП). Механизм управления доступом в БСП тесно связан с RLS (Record Level Security). Шаблоны ограничений доступа, прописанные в ролях (например, БазовыеПраваБСП или ЧтениеДополнительныхСведений), используют параметры сеанса, в частности ТекущийПользователь.
Параметр сеанса ТекущийПользователь — это не просто имя пользователя, под которым мы вошли. Это ссылка на элемент справочника Пользователи. Подробный разбор того, почему параметр сеанса ТекущийПользователь может быть пустым, помогает понять, как происходит сопоставление ИБ-пользователя с элементом справочника при начале работы системы.
Если это сопоставление не удается выполнить, параметр сеанса остается пустым (или Неопределено). Когда запрос с RLS пытается прочитать это значение для проверки прав доступа, происходит ошибка вычисления выражения ограничения, и запрос падает.
Наиболее частая причина описанной проблемы — создание технического пользователя напрямую через Конфигуратор. Однако для интеграций существует более верный путь создания технических пользователей, который гарантирует синхронизацию всех необходимых данных.
Давайте проанализируем, что происходит, когда мы добавляем пользователя в Конфигураторе:
v8users).Пользователи (режим Предприятия) автоматически ничего не создается.При входе под таким пользователем БСП не находит ему соответствия в справочнике. В списке пользователей информационной базы такой пользователь может отображаться красным цветом, сигнализируя о рассинхронизации.
Чтобы исправить ошибку и обеспечить корректную работу HTTP-сервиса с любыми объектами конфигурации (включая ПВХ и Доп. сведения), необходимо выполнить следующие шаги. Рассмотрим их подробно.
Если вы уже создали «кривого» пользователя через Конфигуратор, его лучше удалить, чтобы избежать конфликтов идентификаторов.
В конфигурациях на базе БСП (ЗУП, ERP, КА, УТ) пользователей следует создавать исключительно в режиме «1С:Предприятие». Если вам необходимо создать сразу много сервисных аккаунтов, можно использовать обработку для группового добавления пользователей в типовые конфигурации.
В этот момент система сама создаст пользователя в Конфигураторе и, что самое важное, корректно запишет его УникальныйИдентификатор в реквизиты справочника Пользователи. Связь будет установлена.
Не назначайте роли пользователю напрямую в Конфигураторе! Это может сбить настройки профилей БСП. Вместо этого:
Если после настройки прав доступ всё еще ограничен, попробуйте применить точечный пересчет прав доступа для пользователя, чтобы принудительно обновить кэшированные данные БСП.
Часто бывает так: мы удалили старого пользователя, создали нового с таким же логином, но HTTP-сервис перестал пускать нас, выдавая ошибку 401.
Причина: Веб-сервер (Apache или IIS) и платформа 1С могут кэшировать данные аутентификации пользователя по его уникальному идентификатору (GUID). Поскольку мы пересоздали пользователя, его GUID изменился, но сервер пытается использовать старые данные. В качестве альтернативы стандартным методам авторизации для внешних систем можно рассмотреть реализацию аутентификации по JWT-токену.
Решение:
default.vrd, убедитесь, что в нем не прописаны жесткие привязки к пользователям.В обсуждении проблемы автор темы пришел к выводу, что использование стандартного механизма дополнительных свойств для технической задачи может быть избыточным и сложным из-за RLS. Если ваша задача узкоспециализирована (например, пометка «Не выгружать» для списка сотрудников), рассмотрим альтернативу.
Вместо борьбы с RLS типовой конфигурации, можно создать в расширении собственный Регистр сведений. Это позволит более гибко управлять доступом и избежать влияния глобальных ограничений БСП.
// Пример структуры собственного регистра в расширении
РегистрСведений.Расш_СтатусыВыгрузкиСотрудников
Измерения:
Сотрудник (СправочникСсылка.Сотрудники)
Ресурсы:
НеВыгружать (Булево)
Если вы всё же решили использовать стандартные ДополнительныеСведения, и вы правильно настроили пользователя (как описано выше), рекомендуется использовать программный интерфейс БСП, а не "сырые" запросы. Чтобы лучше ориентироваться в доступных инструментах, изучите справочник по методам БСП с примерами использования.
Используйте модуль УправлениеСвойствами. Он учитывает нюансы кэширования и прав.
// Правильное получение значения доп. свойства
Значение = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаОбъект, СсылкаНаСвойство);
// Или чтение всех свойств объекта сразу
СвойстваИЗначения = УправлениеСвойствами.ЗначенияСвойств(СсылкаНаОбъект);
Давайте подведем итог. Ошибка «Пользователь не существует в справочнике Пользователи» при работе с HTTP-сервисами в ЗУП/ERP — это следствие нарушения регламента администрирования пользователей в системах на базе БСП.