В практике интеграции 1С со сторонними веб-сервисами и сайтами разработчики часто сталкиваются с крайне коварной ситуацией: код обмена, успешно работавший месяцами или даже годами, внезапно перестает функционировать, возвращая ошибку авторизации 401 Unauthorized. При этом при попытке открыть ту же самую ссылку с теми же учетными данными через обычный браузер (даже непосредственно на сервере, где развернута 1С) файл скачивается без каких-либо проблем.
Администраторы целевого сайта, как правило, утверждают, что «ничего не менялось», а в логах они видят лишь поступление неверной пары логин-пароль. В этой статье мы подробно разберем, почему возникает такое расхождение в поведении браузера и платформы 1С, как локализовать проблему и какие конкретные шаги необходимо предпринять для ее устранения.
Для того чтобы решить проблему, нам необходимо понять фундаментальную разницу между тем, как выполняет HTTP-запросы современный браузер (например, Google Chrome, Яндекс.Браузер или Mozilla Firefox) и как это делает платформа 1С через объект HTTPСоединение.
Существует несколько основных причин, из-за которых сервер может отвергать запросы от 1С, успешно пропуская браузерные сессии:
wget, сначала отправляют «пустой» запрос без учетных данных. Получив в ответ требование авторизации, они отправляют повторный запрос с логином и паролем. Если перед сайтом поставили файрвол, прокси или обновили правила веб-сервера (например, Nginx), система безопасности может сразу блокировать первый «пустой» запрос без предоставления шанса на отправку логина и пароля.1C+Enterprise/8.3). Защита расценивает такой запрос как обращение подозрительного бота и блокирует его на корню.Authorization в переменные окружения PHP, из-за чего скрипт авторизации просто «не видит» переданные данные, хотя физически они пришли в заголовках.---
Для того чтобы точно определить, какую схему авторизации требует сервер, выполним диагностический запрос через утилиту curl в командной строке сервера (или воспользуемся вкладкой «Сеть»/Network в режиме разработчика браузера Chrome при первой очищенной сессии).
Запустим командную строку и выполним запрос, запросив только заголовки ответа (флаг -I):
curl -I https://адрес-вашего-сайта.ru/file.xml
Проанализируем полученный ответ. Нас интересует заголовок WWW-Authenticate. Именно он указывает, какой тип авторизации ожидает веб-сервер:
WWW-Authenticate: Basic realm="..." — классическая базовая авторизация (ее 1С понимает по умолчанию).WWW-Authenticate: Digest realm="..." — дайджест-авторизация (требует хэширования, стандартный конструктор 1С может отработать некорректно без ручной сборки заголовков).WWW-Authenticate: Bearer — авторизация по токенам (передача логина и пароля в параметрах соединения не сработает).---
Если веб-сервер стал более жестко реагировать на запросы и не желает обрабатывать двухэтапную авторизацию, нам необходимо отказаться от передачи логина и пароля непосредственно в параметрах инициализации объекта HTTPСоединение.
Вместо этого мы закодируем учетные данные в формат Base64 вручную и сразу же прикрепим их к заголовкам нашего HTTPЗапроса. Таким образом, первый же запрос уйдет на сервер уже авторизованным.
Рассмотрим пример кода, реализующий этот механизм:
// Очистим параметры подключения от логина и пароля, чтобы 1С не пыталась использовать дефолтный механизм
Соединение = Новый HTTPСоединение("имя_хоста.ru", , , , , 15, Новый ЗащищенноеСоединениеOpenSSL());
// Формируем путь к ресурсу
АдресРесурса = "/path/to/file.xml";
Запрос = Новый HTTPЗапрос(АдресРесурса);
// Логин и пароль для авторизации
Логин = "MyUser";
Пароль = "MyPassword123";
// Кодируем пару Логин:Пароль в формат Base64
СтрокаАвторизации = Логин + ":" + Пароль;
// В зависимости от версии платформы получаем двоичные данные строки в кодировке UTF-8
ДвоичныеДанныеСтроки = ПолучитьДвоичныеДанныеИзСтроки(СтрокаАвторизации, КодировкаТекста.UTF8);
ДанныеBase64 = ПолучитьBase64СтрокуИзДвоичныхДанных(ДвоичныеДанныеСтроки);
// Упреждающе добавляем заголовок авторизации Basic
Запрос.Заголовки.Вставить("Authorization", "Basic " + ДанныеBase64);
// Выполняем запрос
Попытка
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
// Успешно получили файл
ДвоичныеДанныеФайла = Ответ.ПолучитьТелоКакДвоичныеДанные();
ДвоичныеДанныеФайла.Записать("C:\temp\downloaded_file.xml");
Сообщить("Файл успешно загружен!");
Иначе
Сообщить("Ошибка запроса! Код состояния сервера: " + Ответ.КодСостояния);
КонецЕсли;
Исключение
Сообщить("Не удалось выполнить подключение: " + ОписаниеОшибки());
КонецПопытки;
---
Если сервер продолжает возвращать ошибку 401 или начинает отдавать 403 Forbidden, велика вероятность, что система защиты сайта блокирует запросы по сигнатуре клиента. Нам нужно заставить сервер поверить, что запрос идет от стандартного браузера Chrome на операционной системе Windows.
Добавим в заголовок запроса параметр User-Agent. Модифицируем наш код следующим образом:
// Создаем запрос
Запрос = Новый HTTPЗапрос(АдресРесурса);
// Устанавливаем заголовки авторизации
Запрос.Заголовки.Вставить("Authorization", "Basic " + ДанныеBase64);
// Маскируем 1С под современный браузер Google Chrome
БраузерныйЮзерАгент = "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", БраузерныйЮзерАгент);
// Отправляем запрос
Ответ = Соединение.Получить(Запрос);
Этот простой шаг в 90% случаев решает проблемы интеграции, когда системные администраторы веб-ресурса без предупреждения подключают защиту от DDoS-атак или парсинга.
---
Если база 1С работает на старом релизе платформы (особенно актуально для старых конфигураций вроде УТ 10.3, КА 1.1 или УПП 1.3), платформа может не поддерживать современные шифры TLS 1.2/1.3 по умолчанию. Браузер при этом соединяется без проблем, так как постоянно обновляется операционной системой.
Для гарантированной работы защищенного протокола https обязательно передавайте в конструктор HTTPСоединение объект инициализации SSL, а также явно указывайте порт HTTPS (443):
// Форсируем использование защищенного соединения OpenSSL
Защита = Новый ЗащищенноеСоединениеOpenSSL();
// Указываем порт 443 для безопасного протокола HTTPS
Соединение = Новый HTTPСоединение("имя_хоста.ru", 443, , , , 30, Защита);
Если это не помогло, проверьте версию платформы 1С:Предприятие. На серверах под управлением устаревших ОС Windows Server 2008/2012 может потребоваться дополнительное включение протоколов TLS 1.2 в системном реестре Windows.
---
Если целевой сайт написан разработчиками на PHP и крутится на веб-сервере Apache или Nginx в режиме FastCGI, то заголовки авторизации могут просто срезаться веб-сервером до того, как запрос попадет в код скрипта. Именно поэтому администратор сайта видит «пустые» логины и пароли в логах скрипта PHP.
В этом случае вам необходимо связаться с администратором сайта и попросить его внести изменения в конфигурационные файлы сервера:
Для веб-сервера Apache (в файл .htaccess в корне сайта нужно добавить директиву проброса заголовка авторизации):
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]
Для веб-сервера Nginx (убедиться, что в блоке обработки PHP-скриптов передается параметр авторизации):
fastcgi_pass_header Authorization;
После применения этих правил на стороне сайта, заголовки авторизации, отсылаемые из 1С, начнут беспрепятственно доходить до PHP-обработчиков сайта, и авторизация начнет проходить в штатном режиме.
---
Если у вас внезапно перестал скачиваться файл из 1С, но скачивается из браузера, действуйте по следующему алгоритму:
curl -I или вкладку Network браузера, чтобы узнать точную схему авторизации (заголовок WWW-Authenticate).HTTPСоединение к явной установке заголовка Authorization со строкой в формате Base64.User-Agent на строку, имитирующую браузер, во избежание блокировок от систем защиты веб-сервера.ЗащищенноеСоединениеOpenSSL() и передавайте порт 443.