В процессе разработки и сопровождения систем на платформе 1С:Предприятие 8.3 многие специалисты сталкиваются с крайне неприятным поведением расширений конфигурации. Суть проблемы заключается в том, что стабильно работающее расширение внезапно «отваливается» — оно перестает применяться для всех пользователей системы, а в журнале регистрации фиксируются ошибки, связанные с безопасным режимом. Особенно часто это происходит в базах, где активно используются внешние подключения или фоновые задания.
Разберем детально, почему это происходит, как механизмы платформы влияют на работу модулей и какие шаги необходимо предпринять для окончательного решения проблемы.
Типичный сценарий выглядит следующим образом: после переноса доработок в расширение (особенно если затрагиваются общие модули или модули объектов) система начинает вести себя нестабильно. При попытке подключения к базе через COM-соединение или при выполнении обмена данными в журнале регистрации появляется запись вида:
Ошибка расширения модуля 'ОбщийМодуль.ИмяМодуля.Модуль': расширение модуля запрещено из-за того, что расширение 'ИмяРасширения' подключено в безопасном режиме.
После возникновения такой ошибки расширение перестает работать не только для того сеанса, который вызвал ошибку, но и для всех остальных активных пользователей. Исправить ситуацию часто помогает только ручное «передергивание» флажка Безопасный режим в списке расширений или перезапуск службы сервера 1С.
Рассмотрим подробнее внутренние механизмы платформы. Основная причина такого поведения в версиях 8.3.9 и некоторых последующих кроется в зарегистрированной ошибке 50010392. Она связана с тем, как серверный кластер 1С обрабатывает первый сеанс обращения к расширению после старта рабочего процесса rphost.
Проанализируем ситуацию: когда рабочий процесс перезапускается (или стартует впервые), он компилирует модули расширений. Если первым обратившимся сеансом оказывается сеанс с ограниченными правами или специфическим контекстом безопасности (например, COM-соединение), платформа инициализирует расширение с флагом Безопасный режим. Из-за ошибки в логике кэширования этот флаг «залипает» в памяти рабочего процесса. Все последующие пользователи, подключаясь к этому же процессу, получают уже скомпилированное в «урезанном» виде расширение. Поскольку в безопасном режиме расширение не имеет права модифицировать серверный код общих модулей, система просто отключает его выполнение во избежание нарушений безопасности.
Выясним, какую роль здесь играет механизм защиты от опасных действий, внедренный в платформу 8.3.9. Даже если вы явно сняли галочку Безопасный режим в свойствах расширения, платформа может принудительно применить его, если:
conf.cfg как база с обязательной проверкой опасных действий.В случае с COM-соединением контекст безопасности часто оказывается более жестким, чем у обычного пользователя в толстом или тонком клиенте, что и провоцирует «вылет» расширения.
Самым правильным и надежным способом решения является переход на релизы платформы, где данная ошибка была официально исправлена. Посмотрим на историю исправлений:
Однако практика показывает, что на более современных ветках (8.3.12–8.3.14) проблема иногда проявлялась снова из-за изменения логики работы фоновых заданий. Если вы используете актуальные конфигурации вроде ERP 2.4/2.5 или Бухгалтерия предприятия 3.0, рекомендуется использовать платформу не ниже 8.3.17.1851 или 8.3.18.1289. В этих версиях механизмы изоляции расширений в разных сеансах были переписаны, что практически исключает «залипание» безопасного режима.
Если обновление платформы по каким-то причинам невозможно в данный момент, проанализируем варианты временного решения проблемы.
1. Настройка профилей безопасности
Если вы используете клиент-серверный вариант, попробуйте настроить профиль безопасности для информационной базы. В консоли администрирования серверов 1С необходимо создать профиль и в нем явно разрешить расширению использование внешних компонентов и небезопасных методов. Убедитесь, что имя расширения в настройках профиля в точности совпадает с его именем в конфигураторе.
2. Программное управление безопасным режимом
Посмотрим на пример кода, который можно внедрить в расширение для принудительной установки режима работы. В модуле расширения, например в процедуре УстановкаПараметровСеанса, можно попытаться программно отключить ограничения, если контекст это позволяет:
Процедура ПриУстановкеПараметровСеанса(СеансНастроен)
// Попытаемся программно снять безопасный режим для текущего сеанса
Если ПолучитьБезопасныйРежим() Тогда
Попытка
УстановитьБезопасныйРежим(Ложь);
Исключение
// Обработка исключения, если прав недостаточно
КонецПопытки;
КонецЕсли;
КонецПроцедуры
3. Использование параметров строки соединения
При использовании COMConnector или V83.Application в строке подключения можно попробовать добавить параметры, влияющие на безопасность. Хотя параметр DisableChildProcessManager=True чаще используется для подавления диалогов, в некоторых случаях это помогает стабилизировать инициализацию окружения.
Разберем еще один неочевидный момент. Статус компиляции расширения часто зависит от того, какой именно сеанс первым обратился к расширению после очистки серверного кэша или перезапуска процесса rphost. Чтобы минимизировать риск, можно настроить регламентное задание, которое будет запускаться сразу после старта сервера под правами администратора и обращаться к функционалу расширения. Это гарантирует, что расширение скомпилируется с полными правами и будет доступно остальным пользователям в правильном контексте.
Для тех, кто работает на современных версиях платформы, важно обратить внимание на свойство расширения «Использует опасные действия». Если ваше расширение выполняет сложные операции (работа с файловой системой, внешние вызовы), и это свойство не настроено корректно в сочетании с Защитой от опасных действий, платформа может превентивно блокировать расширение при попытке его вызова из «сомнительного» сеанса.
Также проверьте Назначение расширения. Существует три варианта: Исправление, Адаптация, Дополнение. Расширения с назначением Исправление (Patch) имеют больше ограничений при работе в безопасном режиме. Для крупных доработок логики лучше использовать тип Адаптация.
Подведем итоги: если ваше расширение «вылетает», в первую очередь проверьте версию платформы и наличие в ней ошибки 50010392. Если обновление невозможно, копайте в сторону профилей безопасности и программного управления режимом исполнения. Помните, что стабильность работы расширений напрямую зависит от чистоты серверного кэша и прав первого сеанса, инициализировавшего расширение в рабочем процессе.