Рассмотрим достаточно распространенную ситуацию при разработке в 1С:Предприятие. Допустим, мы добавили новую обработку в расширение конфигурации и пытаемся программно ее инициализировать с помощью следующего кода:
Функция Обработка_СоздатьИзКонфигурации(ПутьКОбработке)
Результат = Обработки[ПутьКОбработке].Создать();
Возврат Результат;
КонецФункции
Под пользователем с полными правами данный код отрабатывает штатно. Однако, когда функцию вызывает пользователь с ограниченными правами, система прерывает выполнение и выдает ошибку:
[ОшибкаВоВремяВыполненияВстроенногоЯзыка]
по причине:
Нарушение прав доступа!
Путь = ИмяНашейОбработки;
Местонахождение = Конфигурация;
Проанализируем эту ситуацию, разберем по шагам причины возникновения ошибки и выясним, какие именно настройки нужно выполнить, чтобы код заработал у любого нужного нам пользователя.
Часто программисты при возникновении ошибок прав доступа сразу пытаются обернуть проблемный код в УстановитьПривилегированныйРежим(Истина). Разберем, поможет ли это в нашем случае.
Нет, этот метод не решит проблему. Важно понимать архитектурную особенность платформы 1С: привилегированный режим отключает только проверку прав на доступ к данным. То есть он позволяет читать, добавлять, изменять и удалять записи в базе данных, а также игнорирует ограничения на уровне записей (RLS).
Однако привилегированный режим не отключает проверку прав на использование самих объектов метаданных (интерфейсов, отчетов, обработок). Когда мы вызываем метод Создать() у менеджера обработок, платформа проверяет наличие у текущего сеанса базового права «Использование» на конкретный объект метаданных. Обойти это ограничение привилегированным режимом невозможно.
Выясним причину остановки кода. Чтобы метод Создать() отработал успешно, у пользователя обязательно должна быть роль, в которой для требуемой обработки установлен флаг права «Использование». Если предполагается, что обработка будет открываться визуально, то дополнительно требуется право «Просмотр».
Посмотрим на специфику работы с расширениями. Поскольку наша обработка находится в расширении конфигурации, для нее по умолчанию не существует прав у неполноправных пользователей основной конфигурации. Правильный порядок действий выглядит так:
РольИспользованиеНовойОбработки).Проанализируем ситуацию дальше. Даже если мы назначили роли правильно, ошибка может возникнуть из-за настроек безопасности платформы.
Защита от опасных действий: У пользователя в карточке может быть установлен флаг «Защита от опасных действий». Если создаваемая обработка программно выполняет потенциально опасные операции (работа с COM-объектами, файловой системой, интернетом), платформа может заблокировать ее выполнение. Если мы доверяем коду, этот флаг у пользователя можно снять.
Безопасный режим расширения: Обратим внимание на то, что расширения конфигурации по умолчанию подключаются в Безопасном режиме. Если ошибка возникает внутри модуля объекта нашей обработки при инициализации (в процедуре ПриСозданииНаСервере или в блоке инициализации глобальных переменных модуля), то дело именно в этом. В таком случае необходимо открыть карточку расширения в режиме Предприятия и снять галочку «Безопасный режим».
Рассмотрим еще один интересный нюанс, с которым сталкиваются разработчики. При анализе Журнала Регистрации можно заметить странную деталь: платформа пишет Местонахождение = Конфигурация, но не указывает прямой путь к объекту (например, Обработка.ИмяОбработки). Из-за этого может показаться, что система ругается на сам факт вызова менеджера Обработки.
Разберем по шагам, почему это происходит. Это не ошибка, а встроенная функция безопасности 1С. Когда выполняется программное обращение к коллекции метаданных по строковому имени, а у пользователя нет абсолютно никаких прав на видимость этого узла метаданных, платформа скрывает точный тип объекта в тексте ошибки. Выводится лишь общая ошибка доступа к конфигурации, чтобы потенциальный злоумышленник не мог сканировать структуру закрытых метаданных базы.
Посмотрим на пример, когда по бизнес-логике пользователю категорически нельзя давать право на использование данной обработки, но выполнить алгоритм из нее программно необходимо.
В такой ситуации лучше отказаться от программного создания обработки. Рассмотрим правильный архитектурный подход:
Таким образом, программный вызов отработает в привилегированном режиме без проблем с правами доступа к метаданным, так как права на вызов серверных общих модулей регулируются проще, и нам не потребуется программно инициализировать объект обработки.