При работе с внешними HTTP-сервисами, опубликованными на веб-сервере IIS, разработчики 1С часто сталкиваются с ситуацией, когда доступ через обычный браузер работает корректно, а программный вызов из кода 1С возвращает код состояния 401.2. Эта ошибка расшифровывается как «Ошибка конфигурации сервера: авторизация не удалась из-за настроек сервера». Проанализируем причины возникновения этой проблемы и разберем по шагам способы ее решения.
Код состояния 401.2 специфичен для веб-сервера IIS (Internet Information Services). Он возникает в тот момент, когда сервер не может согласовать метод авторизации с клиентом. Простыми словами: сервер ожидает один способ подтверждения личности (например, NTLM или Kerberos), а клиентская база 1С пытается использовать другой или не передает необходимые данные в правильном формате.
Рассмотрим основные причины, почему это происходит:
HTTPСоединение рассчитывает на «Основную авторизацию» (Basic Authentication).Выясним причину, почему стандартный конструктор HTTPСоединение иногда подводит. Платформа 1С не всегда отправляет данные авторизации в первом же запросе. Часто она сначала отправляет «пустой» запрос, ждет от сервера ответ 401 со списком поддерживаемых методов и только потом повторяет попытку. Если IIS настроен строго, он может оборвать соединение сразу.
Самый надежный способ — принудительно добавить заголовок Basic-авторизации в каждый запрос. Разберем, как это сделать программно:
// 1. Подготавливаем данные авторизации
Логин = "ВашЛогин";
Пароль = "ВашПароль";
// 2. Кодируем строку "Логин:Пароль" в формат Base64
СтрокаАвторизации = Логин + ":" + Пароль;
ДвоичныеДанныеАвторизации = ПолучитьДвоичныеДанныеИзСтроки(СтрокаАвторизации, КодировкаТекста.UTF8);
Base64Авторизация = Base64Строка(ДвоичныеДанныеАвторизации);
// Удаляем возможные символы переноса строк, которые иногда добавляет Base64Строка
Base64Авторизация = СтрЗаменить(Base64Авторизация, Символы.ПС, "");
Base64Авторизация = СтрЗаменить(Base64Авторизация, Символы.ВК, "");
// 3. Формируем заголовки запроса
Заголовки = Новый Соответствие;
Заголовки.Вставить("Authorization", "Basic " + Base64Авторизация);
Заголовки.Вставить("Content-type", "application/json; charset=utf-8");
// 4. Выполняем соединение (логин и пароль в конструкторе можно уже не указывать)
Соединение = Новый HTTPСоединение("mybase.ru", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/ser/hs/get", Заголовки);
Ответ = Соединение.Получить(Запрос);
Этот метод заставляет сервер сразу увидеть учетные данные, минуя этап согласования методов, что в 90% случаев решает проблему 401.2.
Проанализируем ситуацию, когда код выполняется на сервере. Часто в системных настройках сервера Windows прописан прокси-сервер, который пытается анализировать трафик 1С. Чтобы исключить его влияние, используем объект ИнтернетПрокси с явным отключением использования прокси.
Посмотрим на пример модификации кода:
// Создаем объект прокси и отключаем использование системных настроек
Прокси = Новый ИнтернетПрокси(Ложь); // Параметр Ложь отключает использование настроек ОС
// Передаем объект прокси пятым параметром в конструктор HTTPСоединение
Соединение = Новый HTTPСоединение(
"mybase.ru",
443,
Логин,
Пароль,
Прокси, // Использование пустого прокси
,
Новый ЗащищенноеСоединениеOpenSSL
);
Если у вас есть доступ к серверу, где опубликована база, стоит проверить файл default.vrd. Этот файл определяет, как 1С взаимодействует с веб-сервером. Обратите внимание на атрибут authentication. Если он настроен некорректно, IIS может пытаться авторизовать пользователя средствами Windows еще до того, как запрос попадет в платформу 1С.
Важные моменты для проверки:
Если вышеописанные методы не помогли, рассмотрим способ глубокой диагностики. IIS предоставляет мощный инструмент — Failed Request Tracing (Трассировка неудачных запросов). Она позволяет детально увидеть, на каком именно этапе (модуле) сервер выдает ошибку 401.2.
Проанализируем логи IIS. Обычно они находятся в папке C:\inetpub\logs\LogFiles. Ищите записи с кодом 401 2. Если рядом стоит подстатус (например, 401 2 5), это даст точную техническую причину отказа, которую можно найти в документации Microsoft.
Помните, что при работе из серверного кода 1С (особенно в клиент-серверном варианте) контекст выполнения отличается от пользовательского. Всегда проверяйте, имеет ли пользователь, под которым запущен кластер 1С, права на выход в интернет и доступ к необходимым сетевым ресурсам.
Используя ручное добавление заголовка Authorization и правильную настройку объекта ИнтернетПрокси, вы сможете обойти большинство ограничений безопасности веб-серверов и обеспечить стабильную работу ваших интеграций.