Рассмотрим распространенную ситуацию, с которой часто сталкиваются разработчики при добавлении внешних отчетов или обработок в типовые конфигурации (например, в «1С:Бухгалтерия предприятия 3.0»). Проанализируем проблему, при которой вызов серверного кода завершается ошибкой прав доступа, несмотря на явную попытку разработчика или типовых механизмов повысить права.
Допустим, мы разработали внешний отчет и подключили его через стандартный справочник ДополнительныеОтчетыИОбработки. В модуле формы отчета (в серверном вызове) выполняется обращение к типовой функции, например:
ОсновнаяОрганизация = БухгалтерскийУчетПереопределяемый.ПолучитьЗначениеПоУмолчанию("ОсновнаяОрганизация");
Этот код по цепочке вызывает функцию в модуле менеджера справочника Организации. Посмотрим на этот типовой код:
Функция ИспользуетсяНесколькоОрганизаций() Экспорт
УстановитьПривилегированныйРежим(Истина);
Возврат Константы.ИспользоватьНесколькоОрганизаций.Получить();
КонецФункции
На строке получения значения константы система выдает ошибку НарушениеПравДоступа, если у пользователя нет роли, дающей право на чтение константы ИспользоватьНесколькоОрганизаций. Возникает резонный вопрос: почему не срабатывает метод УстановитьПривилегированныйРежим(Истина), который как раз и предназначен для обхода таких ограничений?
Главная причина кроется в архитектуре безопасности платформы «1С:Предприятие». Когда мы подключаем дополнительный отчет через стандартную подсистему (БСП), по умолчанию он выполняется в безопасном режиме.
Разберем подробнее, как платформа обрабатывает код в безопасном режиме:
УстановитьПривилегированныйРежим(Истина) блокируется платформой на базовом уровне.УстановитьБезопасныйРежим(Ложь) внутри модуля формы отчета не сработают).Рассмотрим несколько проверенных способов решения этой задачи, от самых простых до архитектурно правильных.
1. Отключение безопасного режима при регистрации обработки
Самый быстрый способ — указать системе, что данному внешнему отчету можно доверять. Для этого в модуле объекта внешнего отчета необходимо найти или добавить экспортную функцию СведенияОВнешнейОбработке(). В структуре параметров регистрации установим свойство безопасного режима в ложь:
ПараметрыРегистрации = ДополнительныеОтчетыИОбработкиКлиентСервер.СведенияОВнешнейОбработке("2.2.2.1");
ПараметрыРегистрации.БезопасныйРежим = Ложь;
Следует учесть, что при добавлении такого отчета в информационную базу администратору потребуется подтвердить предупреждение безопасности, а для самого добавления нужны полные права.
2. Запрос разрешений через механизмы БСП
Если конфигурация использует Библиотеку стандартных подсистем (БСП), мы можем точечно запросить права для работы в безопасном режиме. Для этого в функции СведенияОВнешнейОбработке() необходимо сформировать массив разрешений с использованием программного интерфейса общего модуля РаботаВБезопасномРежиме. Это позволит запросить право на использование привилегированного режима. При загрузке такого отчета администратор явно одобрит запрашиваемые расширенные права.
3. Выдача соответствующих прав пользователю
В случаях, когда политики безопасности компании строго запрещают отключение безопасного режима или выдачу расширенных прав внешним обработкам, самым корректным вариантом будет добавить пользователю роль, разрешающую чтение нужных данных. В нашем примере — назначить роль, включающую право чтения константы ИспользоватьНесколькоОрганизаций.
4. Перенос логики в расширение конфигурации
Проанализируем ситуацию: если наш отчет регулярно обращается к закрытым данным и требует сложной бизнес-логики, целесообразно перевести его из формата внешнего отчета (erf) в формат расширения конфигурации (cfe). Код расширений интегрируется непосредственно в конфигурацию и выполняется вне жестких ограничений безопасного режима внешних обработок. В расширении вызов метода УстановитьПривилегированныйРежим(Истина) будет работать штатно.