Как исправить ошибку авторизации 401.2 при использовании HTTPСоединение в 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с внешними HTTP-сервисами, опубликованными на веб-сервере IIS, разработчики 1С часто сталкиваются с ситуацией, когда доступ через обычный браузер работает корректно, а программный вызов из кода 1С возвращает код состояния 401.2. Эта ошибка расшифровывается как «Ошибка конфигурации сервера: авторизация не удалась из-за настроек сервера». Проанализируем причины возникновения этой проблемы и разберем по шагам способы ее решения.

Поймем природу ошибки 401.2

Код состояния 401.2 специфичен для веб-сервера IIS (Internet Information Services). Он возникает в тот момент, когда сервер не может согласовать метод авторизации с клиентом. Простыми словами: сервер ожидает один способ подтверждения личности (например, NTLM или Kerberos), а клиентская база 1С пытается использовать другой или не передает необходимые данные в правильном формате.

Рассмотрим основные причины, почему это происходит:

  1. Несоответствие методов авторизации: В настройках IIS может быть включена только «Windows-авторизация», в то время как платформа 1С по умолчанию при передаче логина и пароля в конструкторе HTTPСоединение рассчитывает на «Основную авторизацию» (Basic Authentication).
  2. Проблема «двойного прыжка» (Double Hop): Если код выполняется на стороне сервера 1С, и он пытается авторизоваться на другом сервере под учетными данными Windows, система безопасности блокирует передачу данных дальше первого узла.
  3. Влияние прокси-сервера: Настройки прокси в системе могут перехватывать запрос и искажать заголовки авторизации.
  4. Режим ядра IIS: Параметр Kernel-mode authentication в настройках IIS иногда конфликтует с тем, как платформа 1С формирует сетевые пакеты.

Решение 1: Ручное формирование заголовка Authorization

Выясним причину, почему стандартный конструктор 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.

Решение 2: Исключение влияния системного прокси

Проанализируем ситуацию, когда код выполняется на сервере. Часто в системных настройках сервера Windows прописан прокси-сервер, который пытается анализировать трафик 1С. Чтобы исключить его влияние, используем объект ИнтернетПрокси с явным отключением использования прокси.

Посмотрим на пример модификации кода:


// Создаем объект прокси и отключаем использование системных настроек
Прокси = Новый ИнтернетПрокси(Ложь); // Параметр Ложь отключает использование настроек ОС

// Передаем объект прокси пятым параметром в конструктор HTTPСоединение
Соединение = Новый HTTPСоединение(
    "mybase.ru", 
    443, 
    Логин, 
    Пароль, 
    Прокси, // Использование пустого прокси
    , 
    Новый ЗащищенноеСоединениеOpenSSL
);

Решение 3: Проверка конфигурации веб-сервера (default.vrd)

Если у вас есть доступ к серверу, где опубликована база, стоит проверить файл default.vrd. Этот файл определяет, как 1С взаимодействует с веб-сервером. Обратите внимание на атрибут authentication. Если он настроен некорректно, IIS может пытаться авторизовать пользователя средствами Windows еще до того, как запрос попадет в платформу 1С.

Важные моменты для проверки:

Решение 4: Диагностика через трассировку

Если вышеописанные методы не помогли, рассмотрим способ глубокой диагностики. IIS предоставляет мощный инструмент — Failed Request Tracing (Трассировка неудачных запросов). Она позволяет детально увидеть, на каком именно этапе (модуле) сервер выдает ошибку 401.2.

Проанализируем логи IIS. Обычно они находятся в папке C:\inetpub\logs\LogFiles. Ищите записи с кодом 401 2. Если рядом стоит подстатус (например, 401 2 5), это даст точную техническую причину отказа, которую можно найти в документации Microsoft.

Помните, что при работе из серверного кода 1С (особенно в клиент-серверном варианте) контекст выполнения отличается от пользовательского. Всегда проверяйте, имеет ли пользователь, под которым запущен кластер 1С, права на выход в интернет и доступ к необходимым сетевым ресурсам.

Используя ручное добавление заголовка Authorization и правильную настройку объекта ИнтернетПрокси, вы сможете обойти большинство ограничений безопасности веб-серверов и обеспечить стабильную работу ваших интеграций.

← На главную