Приветствуем вас, коллеги! В процессе разработки, поддержки и обновления систем на платформе «1С:Предприятие 8.3» разработчики часто сталкиваются с крайне неочевидными проблемами прав доступа. Типичный сценарий: у пользователя есть все необходимые права на регистр сведений (он может открывать форму списка, просматривать и успешно перезаписывать существующие записи), однако при попытке создать новую запись система выбрасывает критическую ошибку «Нарушение прав доступа». При этом Журнал регистрации хранит молчание, фиксируя лишь лаконичное событие «Ошибка выполнения» без подробностей.
В этой статье мы подробно разберем, почему возникает подобное поведение платформы, как быстро локализовать источник проблемы с помощью штатных инструментов и какие существуют надежные методы решения этой проблемы.
Давайте проанализируем внутренние механизмы платформы. Когда происходит прямое обращение к заблокированной таблице базы данных (например, чтение или запись элемента справочника/документа без соответствующих прав в роли), СУБД или платформенные механизмы безопасности напрямую фиксируют событие категории «Доступ. Отказ в доступе». В этих случаях в Журнале регистрации сразу отображается конкретный объект метаданных.
Однако ситуация меняется, когда в коде происходит обращение к недоступному объекту метаданных типа ПараметрыСеанса. Попытка считывания значения параметра сеанса, на который у текущего пользователя нет прав (например, ПараметрыСеанса.ТекущийПользователь или служебных параметров подсистем БСП), генерирует стандартное исключение среды выполнения (Runtime Exception).
Для платформы это событие выглядит не как классический отказ в доступе к базе данных, а как логический сбой выполнения программного кода (аналогично делению на ноль или обращению к несуществующему свойству структуры). На стороне клиента (особенно в веб-клиенте) такое исключение перехватывается глобальным обработчиком. Чтобы не раскрывать структуру метаданных и внутреннее устройство кода потенциальным злоумышленникам, платформа выводит пользователю обобщенное «Нарушение прав доступа!», а в Журнал регистрации записывает малоинформативное событие «Ошибка выполнения» без подробного стека вызовов.
Если ошибка воспроизводится только на стороне клиента и стандартный лог Журнала регистрации не помогает, воспользуемся отличным встроенным механизмом диагностики, доступным непосредственно в пользовательском интерфейсе:
В этом текстовом блоке вы увидите сырой текст ошибки, возвращенный сервером приложений. Стек вызовов будет содержать точное указание проблемной строки кода:
{ОбщийМодуль.ШаблонныеСобытияФорм.Модуль(142)}: Ошибка при получении значения атрибута контекста (ИмяПараметраСеанса) по причине: Нарушение прав доступа!
Как только мы выяснили, какой именно параметр сеанса (или иной объект) вызывает конфликт, переходим к исправлению. Рассмотрим основные подходы решения этой задачи.
Если бизнес-логика вашей конфигурации требует проверки параметра сеанса при создании записи регистра, но рядовым пользователям нельзя давать прямые права на чтение этого параметра, необходимо временно отключить проверку прав платформой. Для этого обернем вызов в привилегированный режим на сервере или перенесем выполнение кода в привилегированный общий модуль (у которого в свойствах установлен флаг «Привилегированный»):
УстановитьПривилегированныйРежим(Истина);
ТекущееЗначение = ПараметрыСеанса.ИмяПараметраСеанса;
УстановитьПривилегированныйРежим(Лжь);
Обратите внимание: данный подход работает только на стороне сервера. Платформа проигнорирует попытку включения привилегированного режима на стороне клиента.
Часто переопределенные кнопки «Создать» или обработчики событий вызываются внутри внешних обработок заполнения, подключенных через механизм дополнительных отчетов и обработок (БСП). Помните, что такие обработки по умолчанию запускаются платформой в безопасном режиме.
В безопасном режиме вызовы метода УстановитьПривилегированныйРежим() полностью игнорируются платформой. Если дело в этом, то программно обойти ограничение не получится — пользователю придется физически предоставить права на чтение данного параметра сеанса в его роли в конфигураторе.
Если подобные ошибки начали лавинообразно возникать после очередного обновления конфигурации, причина кроется в нетиповых (самописных) ролях ваших пользователей. При обновлении типовых конфигураций разработчики 1С часто добавляют новые служебные параметры сеанса (контроль дат запрета изменения, параметры интеграции и т.д.). В типовые роли права добавляются автоматически, а вот самописные роли остаются без изменений. Проанализируйте роли проблемных пользователей и вручную добавьте право «Получение» на новые параметры сеанса.
Давайте разберем три альтернативных метода отладки, если запуск возможен только из веб-клиента и стандартный отладчик не перехватывает сессию:
-debug -http). После этого в конфигураторе через меню Отладка -> Подключение вы сможете найти и подключить сеанс нужного веб-клиента.logcfg.xml в каталоге настроек (например, C:\Program Files\1cv8\conf\) следующего содержания:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\v8\logs" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
После воспроизведения ошибки откройте сформированный лог-файл в папке C:\v8\logs. По событию EXCP (Exception) вы мгновенно обнаружите полную цепочку процедур и функций, приведших к обращению к закрытому параметру сеанса.