Как устранить ошибку при работе с ресурсом /e1cib/additionalAuthSettings после обновления платформы 1С?

← На главную

После перехода на новые релизы платформы 1С:Предприятие (в частности, начиная с версии 8.3.26.1521) администраторы и пользователи веб-клиента могут столкнуться с внезапным сбоем при попытке открыть информационную базу через браузер. Вместо привычного диалога авторизации на экране отображается системное сообщение: HTTP: Bad request. Ошибка при работе с ресурсом /e1cib/additionalAuthSettings. Проанализируем, почему возникает данная неполадка и какими способами ее можно устранить.

Назначение ресурса /e1cib/additionalAuthSettings и механизм сбоя

Разберем внутреннюю логику работы платформы. Системный эндпоинт /e1cib/additionalAuthSettings задействуется веб-клиентом 1С на самом раннем этапе инициализации сеанса — еще до того, как пользователю будет показана форма ввода логина и пароля. Через этот служебный адрес происходят следующие действия:

Согласование версии внутреннего протокола аутентификации (в заголовке 1C-AuthSettingsProtoVersion).
Передача параметров двухфакторной аутентификации (2FA), если она включена в базе.
Получение настроек провайдеров OpenID и OpenID Connect.
Передача признаков сохранения учетных данных.

Выясним причину возникновения ошибки HTTP 400 (Bad request). В операционных системах семейства Windows веб-сервер IIS традиционно не чувствителен к регистру символов в строке URL. Если виртуальный каталог опубликован как Baza_Buh, веб-сервер без проблем перенаправляет запросы вида http://Server1S/BAZA_BUH или http://Server1S/baza_buh в библиотеку модуля расширения wsisapi.dll.

Однако в платформе 8.3.26 была значительно ужесточена валидация относительных путей. Модуль веб-адаптера 1С сверяет входящий относительный URL с дескриптором публикации default.vrd (а именно с атрибутом base) и своим внутренним контекстом. Если в имени базы хотя бы один символ указан не в том регистре (например, заглавные буквы вместо строчных), платформа не может сопоставить запрос с контекстом и возвращает код ошибки 400 Bad Request. При этом имя самого сервера в начале URL может быть указано в любом регистре, так как его разбор осуществляет сетевой стек и сам веб-сервер.

Способ 1. Синхронизация регистра в ссылках и ярлыках

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

Откроем файл дескриптора публикации default.vrd в каталоге публикации базы на веб-сервере (например, C:\inetpub\wwwroot\Baza_Buh\default.vrd).
Найдем корневой узел и проверим значение атрибута base. Например, если в файле указано base="/Baza_Buh", значит, каноническое имя публикации — Baza_Buh.
Обновим ссылки в закладках браузеров у пользователей, чтобы регистр символов полностью совпадал с атрибутом base.
Если пользователи запускают тонкий клиент по ссылке на веб-сервер, проверим списки информационных баз (файлы ibses.v8i) и приведем строки подключения к корректному регистру.

Способ 2. Автоматическое исправление регистра через модуль URL Rewrite в IIS

Чтобы исключить влияние человеческого фактора при ручном вводе адреса пользователями, настроим веб-сервер IIS на автоматическую нормализацию адресов с помощью официального модуля URL Rewrite. Рассмотрим два варианта настройки.

Вариант А: Приведение входящих адресов к нижнему регистру (To Lower Case)

Если все базы публикуются строчными буквами, настроим общее правило для сайта, преобразующее все входящие запросы в нижний регистр. Откроем конфигурационный файл web.config в корне сайта IIS и добавим правило перезаписи:


<rewrite>
    <rules>
        <rule name="ConvertToLowercase" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Вариант Б: Перенаправление конкретного ошибочного имени на каноническое

Если информационная база имеет смешанный регистр (например, Baza_Buh), настроим точечное перенаправление входящих запросов независимо от регистра ввода:


<rewrite>
    <rules>
        <rule name="RedirectToCanonicalCase" stopProcessing="true">
            <match url="^baza_buh(.*)" ignoreCase="true" />
            <conditions>
                <add input="{URL}" pattern="^/Baza_Buh" negate="true" />
            </conditions>
            <action type="Redirect" url="/Baza_Buh{R:1}" redirectType="Found" />
        </rule>
    </rules>
</rewrite>

В этом случае любое обращение (хоть /BAZA_BUH, хоть /baza_buh) будет перенаправлено веб-сервером на точный адрес /Baza_Buh еще до передачи управления обработчику 1С, что предотвратит ошибку additionalAuthSettings.

Способ 3. Корректная перепубликация информационной базы

При переходе между версиями платформы (особенно с ветки 8.3.25 на 8.3.26) обязательно выполняем повторную публикацию веб-клиента. Это гарантирует, что дескриптор default.vrd сформирован по стандартам текущей версии и привязан к актуальным модулям расширения.

Запустим 1С:Предприятие в режиме Конфигуратора от имени администратора.
Перейдем в меню Администрирование — Публикация на веб-сервере...
Проверим поле Имя: рекомендуется задавать имя исключительно строчными буквами (например, baza_buh) без использования пробелов и специальных символов. Это обеспечивает кроссплатформенную совместимость как с IIS под Windows, так и с Apache / Nginx под управлением Linux.
Нажмем кнопку Опубликовать для перезаписи файла default.vrd и перезапуска пула веб-сервера.

Посмотрим на структуру корректного файла default.vrd после чистой публикации:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/baza_buh"
       ib="Srvr=Server1S;Ref=Baza_Buh;">
    <ws enable="false"/>
    <httpServices publishByDefault="true"/>
</point>

Обратим внимание на атрибут base: значение /baza_buh должно посимвольно совпадать с именем каталога веб-сервера и адресом, по которому подключаются клиенты.