Как подменить User-Agent в ПолеHTMLдокумента в 1С?

← На главную

При интеграции 1С с внешними веб-сервисами, CRM-системами или сайтами через встроенное ПолеHTMLдокумента разработчики часто сталкиваются с проблемой совместимости. Современные веб-ресурсы активно защищаются от роботов и парсеров, анализируя заголовок User-Agent, который передает браузер. По умолчанию встроенный в платформу 1С движок WebKit передает специфическую строку идентификации, содержащую подпись V8WebKit. Сторонние сайты (например, Zoho, Google-сервисы и другие) мгновенно распознают этот заголовок и блокируют доступ, требуя использовать современный браузер, такой как Google Chrome или Mozilla Firefox. В этой статье мы подробно разберем, почему стандартные методы подмены не работают, и рассмотрим рабочие альтернативные варианты решения этой задачи.

Почему не работает прямая подмена через JavaScript?

Первое, что пытается сделать большинство разработчиков — это изменить свойства объекта navigator или clientInformation на стороне загруженного HTML-документа. Разберем типичный пример кода, который часто пытаются использовать в модуле формы 1С:


// Попытка изменить версию приложения
Элементы.ПолеHTML.Документ.defaultView.clientInformation.appVersion = "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36";

// Попытка изменить сам User-Agent
Элементы.ПолеHTML.Документ.defaultView.navigator.userAgent = "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36";

Проанализируем ситуацию: почему этот код не приносит желаемого результата и сайт по-прежнему видит исходный движок 1С? Дело в том, что в современных браузерных движках (включая WebKit, используемый в платформе 1С) свойства navigator.userAgent и navigator.appVersion защищены от записи на уровне спецификации веб-стандартов. Они имеют атрибут read-only (только для чтения). Попытка напрямую присвоить им новое строковое значение просто игнорируется интерпретатором JavaScript без вызова ошибок, и свойства сохраняют свои исходные значения.

Решение 1. Динамическое переопределение свойств JavaScript на клиенте

Если целевой сайт проверяет параметры браузера исключительно с помощью скриптов уже после загрузки страницы, мы можем применить обходной путь. Вместо прямого изменения свойства мы можем переопределить его дескриптор (геттер) с помощью метода Object.defineProperty. Выясним, как это выглядит на практике:


Object.defineProperty(navigator, 'userAgent', {
    get: function () { 
        return 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'; 
    },
    configurable: true
});

Этот скрипт можно внедрить в тело загружаемого HTML-документа или выполнить его принудительно через метод ПолеHTMLдокумента.Документ.defaultView.eval() сразу после инициализации страницы. Однако у этого метода есть критически важное ограничение: он срабатывает только после того, как страница начала загружаться. Это означает, что самый первый HTTP-запрос (GET-запрос на получение самой HTML-страницы) все равно уйдет на сервер с оригинальным заголовком V8WebKit. Если сервер выполняет проверку на своей стороне (backend) до отдачи контента, этот способ не сработает.

Решение 2. Использование локального прокси-сервера (Fiddler / Squid)

Наиболее надежный способ изменить HTTP-заголовки запросов, отправляемых из ПолеHTMLдокумента — это использование промежуточного прокси-сервера. Этот метод позволяет перехватывать сетевые запросы от процесса 1С и модифицировать их на лету.

Разберем по шагам, как работает данная схема:

На компьютере пользователя или в локальной сети разворачивается легковесный прокси-сервер (например, Fiddler, Charles или Squid).
В операционной системе или непосредственно в настройках операционной системы для приложения 1cv8.exe прописывается маршрутизация трафика через этот прокси.
На прокси-сервере настраивается простое правило перезаписи (Rewrite Rule): если HTTP-запрос содержит в заголовке User-Agent подстроку V8WebKit, она автоматически заменяется на полноценную строку современного браузера Chrome.

Продвинутые прокси-серверы позволяют не только подменять заголовки пакетов, но и автоматически инжектировать (внедрять) JS-код переопределения свойств (описанный в Способе 1) в тело всех приходящих HTML-ответов. Это гарантирует стопроцентную совместимость: и веб-сервер, и скрипты внутри страницы будут абсолютно уверены, что сессия запущена в полноценном Google Chrome.

Решение 3. Использование внешних библиотек автоматизации (Selenium WebDriver)

Если стандартный встроенный браузер 1С категорически отказывается работать со сложным современным веб-интерфейсом стороннего сервиса, лучшим решением будет полный отказ от встроенного ПолеHTMLдокумента в пользу профессиональных инструментов автоматизации тестирования, таких как Selenium WebDriver.

Selenium запускает полноценный, установленный в системе браузер (Chrome, Firefox, Edge) в режиме автоматического управления. Для интеграции Selenium с 1С обычно используется запуск внешних скриптов (например, на Python) или обращение к Selenium через COM-объекты.

Посмотрим на пример концептуальной схемы работы из 1С через запуск внешнего сценария:


// Создание файла конфигурации или запуск готового скрипта автоматизации
ПутьКИнструменту = "C:\SeleniumDrivers\chromedriver.exe";
ПараметрыЗапуска = "--user-agent=""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36""";

// Запуск браузера с нужным User-Agent из кода 1С
ЗапуститьПриложение(ПутьКИнструменту + " " + ПараметрыЗапуска);

Использование Selenium полностью снимает проблему совместимости веб-страниц, так как рендеринг и выполнение JS-сценариев происходят в настоящем, актуальном браузере, а не в устаревшем и урезанном контейнере платформы 1С.

Решение 4. Использование внешних ActiveX / COM-компонент (WebKitX)

Для разработчиков, которые хотят сохранить интерфейс браузера непосредственно внутри форм 1С, но при этом иметь полный контроль над его заголовками, куками и настройками, существуют специализированные коммерческие библиотеки. Одним из таких решений является библиотека WebKitX CEF3 Active X.

Этот компонент представляет собой ActiveX-обертку вокруг движка Chromium (CEF3). Он легко интегрируется на форму 1С как внешний объект управления. В отличие от стандартного 1С-WebKit, WebKitX предоставляет разработчику полноценный COM-интерфейс, через который можно управлять абсолютно любыми параметрами сетевого взаимодействия.

Пример настройки User-Agent при инициализации компонента выглядит следующим образом:


// Предположим, что Элементы.WebKitActiveX - это добавленный на форму ActiveX-объект
Элементы.WebKitActiveX.Settings.user_agent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 Safari/537.36";
Элементы.WebKitActiveX.Open("https://target-website.com");

Единственным существенным недостатком такого подхода является необходимость приобретения коммерческой лицензии на использование стороннего компонента и сложность его дистрибуции на рабочие места пользователей.

Эволюция платформы 1С и переход на WebView2

В заключение проанализируем развитие самой платформы 1С. В старых версиях технологической платформы разработчики были жестко ограничены устаревшим движком WebKit. Однако, начиная с современных релизов платформы 1С (начиная с версии 8.3.15 и новее), при работе в среде Windows 10 и выше, платформа осуществляет автоматический переход на использование компонента Microsoft Edge WebView2, работающего на базе Chromium.

Переход на WebView2 автоматически решает большинство проблем совместимости "из коробки", так как данный движок по умолчанию передает современный User-Agent и поддерживает все актуальные стандарты веб-разработки. Тем не менее, если вам требуется тонкая настройка заголовков под конкретную задачу автоматизации в старых конфигурациях, наиболее надежными и проверенными временем решениями остаются использование локального прокси-сервера или интеграция с Selenium.