При разработке и публикации веб-сервисов на платформе 1С:Предприятие программисты часто сталкиваются с ситуацией, когда сервис успешно опубликован и доступен через браузер (например, Internet Explorer или Chrome), но при попытке программного подключения из другой базы 1С система выдает ошибку «Аутентификация пользователя не выполнена» — в такой ситуации пригодится обработка настройки обмена через веб-сервисы. Это происходит даже в тех случаях, когда логин и пароль указаны абсолютно верно в конструкторе WSОпределения.
В этой статье мы подробно разберем, почему возникает такая ситуация, проанализируем механизмы работы веб-сервера IIS и платформы 1С, а также рассмотрим несколько способов решения проблемы (что крайне важно при организации обмена данными между базами 1С) — от простых правок файла публикации до глубокой настройки прав доступа и пулов приложений. Для решения подобных задач есть система управления интеграциями и маршрутизации обменов.
Разберем типичный сценарий. Программист использует следующий код для подключения к сервису:
Определение = Новый WSОпределения("http://ServerTEST/TEST/ws/ws1.1cws?wsdl", "Логин", "Пароль");
В ответ система выбрасывает исключение об ошибке аутентификации. Однако при вводе той же ссылки в браузере появляется стандартное окно ввода учетных данных, после чего корректно отображается XML-описание WSDL. Выясним причину этого различия. Браузеры по умолчанию умеют работать с различными протоколами аутентификации, включая NTLM (Windows-авторизация). Если на веб-сервере (IIS) включена только проверка подлинности Windows, браузер прозрачно для пользователя (или через запрос пароля) передает данные. Метод WSОпределения в 1С при определенных настройках может ожидать Basic-авторизацию или вовсе не получать корректного ответа от сервера из-за многошагового процесса подтверждения NTLM.
Как показала практика обсуждения, одним из самых эффективных и быстрых способов является указание учетных данных пользователя 1С непосредственно в файле публикации. Это позволяет веб-серверу авторизоваться в базе данных от имени конкретного пользователя еще до того, как запрос будет передан в логику веб-сервиса.
Рассмотрим по шагам, как это сделать:
default.vrd и откройте его любым текстовым редактором.<point>. Нам необходимо добавить в него атрибуты для авторизации.Пример модифицированного файла default.vrd:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/TEST"
ib="Srvr=ServerName;Ref=BaseName;"
usr="Логин"
pwd="Пароль">
<ws>
<point name="ws1" alias="ws1.1cws"/>
</ws>
</point>
Важный нюанс: После того как вы прописали usr и pwd в файле default.vrd, в коде 1С при создании объекта WSОпределения логин и пароль указывать уже не нужно. Подключение будет выглядеть так:
Определение = Новый WSОпределения("http://ServerTEST/TEST/ws/ws1.1cws?wsdl");
Проанализируем настройки веб-сервера Internet Information Services (IIS). Если вы не хотите хранить пароль в открытом виде в файле default.vrd, необходимо правильно настроить методы проверки подлинности для виртуального приложения 1С.
Для корректной работы WSОпределения с передачей логина/пароля в параметрах выполните следующее:
HTTPСоединение и WSПрокси.Часто выясним причину ошибки не в коде, а в правах доступа операционной системы. Веб-сервер IIS работает от имени определенного пользователя (обычно это IIS AppPool\ИмяПула или NetworkService). Если у этого системного пользователя нет прав на чтение компонентов 1С, он может выдать общую ошибку аутентификации.
Проверьте следующие права доступа:
C:\Program Files\1cv8\8.3.XX.XXXX\bin).Рассмотрим подробнее влияние символов в логине и пароле. Использование кириллицы в логинах веб-сервисов часто приводит к ошибкам, так как разные веб-серверы могут по-разному интерпретировать кодировку заголовков. Постарайтесь использовать для сервисных учетных записей только латиницу.
Также обратите внимание на спецсимволы в пароле. Такие знаки как @, :, / являются зарезервированными в URL. Если они присутствуют в пароле, они могут исказить строку запроса. В таких случаях рекомендуется:
Authorization через объект HTTPСоединение, предварительно закодировав строку "логин:пароль" в Base64.Разберем еще несколько важных аспектов, которые могут влиять на результат:
1. Кэширование WSDL. Иногда после изменения настроек в default.vrd или IIS ошибка сохраняется. Это может быть связано с тем, что 1С кэширует описание сервиса. Попробуйте добавить произвольный параметр в строку запроса, чтобы принудительно обновить кэш:
"http://Server/Base/ws/service?wsdl&nocache=1"
2. Разрядность пула приложений. Если вы используете 64-битную ОС, убедитесь, что в настройках пула приложений IIS параметр «Разрешить 32-разрядные приложения» установлен в соответствии с разрядностью установленного расширения веб-сервера 1С (wsapidll.dll). Несоответствие разрядности часто приводит к сбоям в модуле аутентификации.
3. Пул соединений. В файле default.vrd внутри тега <point> можно настроить параметры пула соединений:
<pool size="10" timeout="5" maxConnections="20"/>
Это не решает проблему авторизации напрямую, но предотвращает ошибки «Превышено максимальное количество соединений», которые могут ошибочно интерпретироваться как проблемы с доступом при высокой нагрузке.
Подводя итог, можно сказать, что наиболее стабильным решением для внутренних интеграций является прописывание параметров usr и pwd в файле default.vrd в сочетании с включенной анонимной авторизацией на стороне IIS. Это исключает влияние протоколов Windows на процесс передачи учетных данных и гарантирует стабильную работу веб-сервиса 1С.