Почему при обращении к веб-сервису 1С в журнале регистрации фиксируется двойная авторизация?

← На главную

Рассмотрим достаточно распространенную ситуацию, с которой сталкиваются разработчики при интеграции внешних систем (например, интернет-сайтов на PHP) с базой 1С:Предприятие 8.2 или 8.3 через веб-сервисы. Суть проблемы заключается в том, что при совершении одного логического вызова метода веб-сервиса в Журнале регистрации 1С фиксируется не один, а сразу два последовательных входа и выхода пользователя (сеанса). Проанализируем, почему это происходит, насколько это критично и как можно оптимизировать этот процесс.

Анализ исходной ситуации

В нашем распоряжении имеется следующая связка: сервер под управлением Windows Server 2008 R2, веб-сервер Apache 2.2 и база 1С 8.2. При вызове метода UpdateOrderOnlineStore со стороны сайта, в журнале регистрации мы наблюдаем следующую картину:

Запись 1: Сеанс 857 Начало — Аутентификация WebServiceUser — Завершение.

Запись 2: Сеанс 861 Начало — Аутентификация WebServiceUser — Завершение.

Разберем по шагам, какие технические аспекты приводят к такому поведению системы. Выясним, является ли это ошибкой платформы 1С или особенностью работы сетевых протоколов и клиентских библиотек.

Причина №1: Запрос WSDL-описания веб-сервиса

Наиболее вероятной причиной двойной авторизации является механизм работы SoapClient в PHP (или аналогичных библиотек в других языках). Проанализируем типичный код вызова на стороне сайта:


$client = new SoapClient("http://server/base/ws/service.1cws?wsdl", array("login" => "user", "password" => "pass"));
$result = $client->UpdateOrderOnlineStore($params);

Когда мы создаем объект SoapClient и передаем ему URL с параметром ?wsdl, происходит следующее:

Первый запрос: Клиент обращается к серверу 1С, чтобы получить XML-описание структуры веб-сервиса (WSDL-файл). Для получения этого файла требуется авторизация. 1С открывает сеанс, отдает файл и тут же закрывает сеанс. Это и есть первая запись в журнале регистрации.
Второй запрос: Клиент, получив структуру сервиса, формирует уже непосредственный SOAP-запрос для вызова метода UpdateOrderOnlineStore. Это отдельное HTTP-соединение, которое снова требует авторизации. 1С открывает второй сеанс, выполняет код метода и закрывает сеанс. Это вторая запись.

Как решить: Для исключения первого запроса необходимо использовать кэширование WSDL на стороне клиента. В PHP это настраивается параметром soap.wsdl_cache_enabled в php.ini или передачей параметров в конструктор. Если структура сервиса меняется редко, можно скачать WSDL-файл локально на сервер сайта и инициализировать клиент, указывая путь к локальному файлу. В этом случае обращение за метаданными к 1С происходить не будет.

Причина №2: Механизм HTTP-авторизации (Challenge-Response)

Проанализируем ситуацию с точки зрения протокола HTTP. Веб-сервер Apache (или IIS) при использовании Basic Authentication часто работает по схеме "вызов-ответ":

Клиент отправляет запрос без заголовка Authorization.
Сервер отвечает кодом 401 Unauthorized и заголовком WWW-Authenticate.
Клиент повторяет запрос, уже включая заголовок с логином и паролем.

В некоторых конфигурациях модуля расширения веб-сервера 1С даже попытка неавторизованного доступа может инициировать краткосрочное обращение к системе безопасности 1С. Хотя чаще всего 401-я ошибка не создает полноценного сеанса в журнале регистрации, в старых версиях платформы 8.2 наблюдались особенности, когда "предварительный" запрос мог фиксироваться платформой.

Причина №3: Отсутствие Keep-Alive соединений

Если между сайтом и 1С не поддерживается режим Keep-Alive (постоянное соединение), то каждый чих клиентского приложения будет порождать новое TCP-соединение и, как следствие, новый процесс рукопожатия (handshake) авторизации. Рассмотрим настройки веб-сервера Apache. Если параметр KeepAlive установлен в значение Off, то сервер принудительно закрывает соединение после каждого ответа. При интенсивном обмене данными (например, раз в минуту от нескольких сайтов) это создает лишнюю нагрузку на серверную часть 1С, так как инициализация сеанса — операция ресурсоемкая.

Причина №4: Особенности платформы 1С 8.2 и режима совместимости

Выясним причину, связанную с архитектурой старых версий 1С. В платформе 8.2.19 механизм управления сеансами веб-сервисов работал менее эффективно, чем в современных версиях 8.3. В те времена не существовало полноценного пула соединений для веб-сервисов в том виде, в котором он есть сейчас.

Иногда система могла создавать один сеанс для проверки прав доступа к самому объекту ВебСервис в метаданных, а второй — непосредственно для исполнения кода модуля. Это поведение часто зависело от того, как опубликована база и какие параметры указаны в файле default.vrd.

Как провести детальную диагностику?

Для того чтобы точно определить, какой из факторов является решающим в вашем случае, рекомендуем воспользоваться инструментами анализа трафика. Рассмотрим последовательность действий:

Использование Fiddler или Wireshark: Запустите перехват трафика на стороне клиента или сервера. Посмотрите, сколько реально HTTP-запросов уходит в сторону 1С. Если вы видите два запроса POST или GET, значит проблема в логике работы клиента (например, запрос WSDL).
Анализ логов Apache: Изучите access.log веб-сервера. Сопоставьте время запросов с записями в журнале регистрации 1С. Если в логах Apache за секунду проходит два обращения с кодом 200, то 1С абсолютно честно регистрирует два входа.
Проверка файла публикации: Посмотрите содержимое файла default.vrd. Обратите внимание на параметры пула соединений (для 8.3 это poolSize, poolTimeout), хотя для 8.2 возможности настройки пула были крайне ограничены.