При публикации и первоначальном тестировании SOAP веб-сервисов в 1С разработчики нередко сталкиваются с ситуацией: веб-сервис опубликован, при попытке открыть его адрес в браузере появляется стандартное окно ввода логина и пароля HTTP Basic Auth, однако ввод корректных учетных данных существующего пользователя базы ни к чему не приводит. Окно авторизации запрашивает логин и пароль снова и снова, либо сервер возвращает ошибку доступа. Разберем детально, почему это происходит и как правильно наладить доступ к веб-сервису.
Проанализируем главную причину, с которой столкнулся автор темы. По протоколу HTTP при базовой аутентификации (Basic Authentication) браузер кодирует строку вида Логин:Пароль с использованием алгоритма Base64. Исторически стандарт Basic Auth ориентировался на таблицу символов Latin-1 (ISO-8859-1).
Когда мы используем имя пользователя на русском языке (например, Администратор), различные браузеры и веб-серверы могут кодировать кириллические символы по-разному (в UTF-8 или Windows-1251). В результате модуль расширения веб-сервера 1С получает последовательность байтов, не совпадающую с внутренним представлением имени пользователя в базе данных, и отклоняет попытку входа. Веб-сервер снова возвращает код ответа 401 Unauthorized, провоцируя повторное появление диалогового окна.
Разберем по шагам, как исправить эту ситуацию:
ws_user или service_admin.ПолныеПрава для тестовой проверки).Рассмотрим вторую распространенную проблему: попытку подключения под учетной записью без пароля. Многие веб-серверы (включая Apache и Microsoft IIS), а также отдельные браузеры и клиенты SOAP обрабатывают пустой пароль в связке Basic Auth некорректно. Строка авторизации в таких случаях может расцениваться клиентом как неполная или поврежденная, из-за чего заголовок Authorization вовсе отсекается или передается без разделителя.
Важное правило: для пользователей 1С, под которыми выполняются обращения к веб-сервисам и HTTP-сервисам, пароль всегда должен быть заполнен.
Посмотрим на структуру URL-адреса, к которому выполнялось обращение. При попытке перейти по прямому пути к дескриптору вида http://localhost/base/ws/base.1cws веб-сервер не получает инструкции о том, какое именно действие требуется выполнить. Запрос типа GET без дополнительных параметров к точке входа сервиса платформой 1С не поддерживается и может вызывать ошибку метода или сбой сеанса.
Для того чтобы просмотреть WSDL-описание сервиса в окне браузера и убедиться в работоспособности точки подключения, необходимо обязательно дописывать параметр ?wsdl:
http://localhost/base/ws/base.1cws?wsdl
Если авторизация проходит успешно, браузер вернет XML-документ с описанием типов, сообщений, операций и точек подключения веб-сервиса.
Выясним причину возможных конфликтов, если публикация выполняется на Microsoft Internet Information Services (IIS). По умолчанию IIS может перехватывать процесс аутентификации, если в настройках сайта включена проверка подлинности Windows (Windows Authentication) или базовая аутентификация самой операционной системы.
В этом случае IIS пытается сопоставить вводимый логин с локальными пользователями Windows или домена Active Directory, даже не передавая управление библиотеке расширения 1С. Чтобы исключить подобное поведение:
Если требуется полностью исключить интерактивный ввод учетных данных при обращении к веб-сервису, рассмотрим возможность передачи данных подключения прямо в файле публикации default.vrd.
В каталоге публикации базы на веб-сервере найдем файл default.vrd и откроем его в текстовом редакторе. В атрибуте ib строки подключения укажем пользователя и пароль:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/base"
ib="Srvr=server1c;Ref=base;usr=ws_user;pwd=SecretPass;">
<ws>
<point name="base" alias="base.1cws" enable="true"/>
</ws>
</point>
При такой конфигурации веб-сервер будет прозрачно авторизовывать входящие подключения под пользователем ws_user, и окно ввода логина и пароля в браузере запрашиваться не будет.