Разберем распространенную, но крайне коварную ситуацию: вы успешно опубликовали базу 1С на веб-сервере Internet Information Services (IIS), веб-клиент открывается без проблем, но при попытке обращения к HTTP-сервису (особенно если он реализован в расширении для интеграции между системами 1С без боли) система возвращает ошибку 401.5 — Ошибка авторизации или 404 — Ресурс не найден. Проанализируем причины этого поведения и пошагово выясним, как настроить сервер для стабильной работы. Для настройки постоянной синхронизации данных по расписанию без изменения конфигураций применяется программа автоматического обмена между базами 1С.
Для начала проанализируем, что именно сообщает нам сервер. Ошибка 401.5 (Authentication failed by an ISAPI/CGI application) специфична для IIS. Она означает, что сам веб-сервер принял запрос, но «споткнулся» на этапе передачи управления внешнему модулю — в нашем случае это библиотека wsisapi.dll, которая отвечает за взаимодействие IIS с платформой 1С.
Часто в журналах регистрации 1С при этом можно увидеть записи о неудачном сеансе пользователя NT AUTHORITY\USR. Рассмотрим подробнее, почему это происходит. При обращении к сервису IIS сначала пытается выполнить проверку подлинности с использованием системной учетной записи. Если в настройках публикации не задан жестко пользователь, 1С ожидает передачи авторизационных данных (заголовка Authorization). Если происходит конфликт между методами аутентификации Windows и анонимным доступом, модуль wsisapi.dll может отклонить запрос еще до того, как дело дойдет до проверки прав пользователя внутри базы 1С. На этом этапе полезно убедиться в корректности отправляемого запроса. Для решения этой задачи можно использовать инструмент для тестирования REST API и проверки HTTP-запросов внутри 1С.
Выясним одну из самых неочевидных причин возникновения ошибок 404 и 401.5. В операционных системах семейства Windows пути к файлам обычно нечувствительны к регистру, однако для веб-серверов и протокола HTTP это не всегда так.
Важный момент: если вы используете веб-клиент 1С (заходите в базу через браузер), IIS часто прощает несоответствие регистра в имени базы. Но как только мы переходим к HTTP-сервисам, правила ужесточаются. Проанализируем ситуацию: если ваша публикация называется ka_copy (строчными буквами), а в строке запроса к сервису вы указываете KA_copy (заглавными), сервер может выдать ошибку авторизации или заявить, что ресурс не найден.
Это происходит потому, что маршрутизация внутри модуля wsisapi.dll для REST и HTTP запросов жестко привязана к параметру base, указанному в файле default.vrd. Разберем пример правильного обращения:
Если в файле default.vrd указано:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/ka_copy"
ib="Srvr=ServerName;Ref=BaseName;">
Тогда адрес вашего сервиса должен строго соответствовать этому регистру в части имени публикации:
http://server/ka_copy/hs/MyService/v1/getData
Если вы измените хотя бы одну букву в ka_copy на заглавную, механизм сопоставления обработчиков может дать сбой, что приведет к ошибке 401.5.
Рассмотрим еще одну вероятную причину — недостаток прав доступа. Часто администраторы дают права пользователю IUSR только на папку, где лежит файл публикации default.vrd, забывая о самих бинарных файлах 1С.
Для корректной работы расширений и HTTP-сервисов необходимо, чтобы учетная запись, под которой запущен Пул приложений (Application Pool) в IIS, имела права «Чтение и выполнение» на каталог bin установленной платформы 1С. Проанализируем цепочку вызова: запрос приходит в IIS -> передается в wsisapi.dll -> библиотека загружает компоненты платформы. Если у пользователя пула приложений нет прав на запуск wsisapi.dll по пути ее фактического расположения, мы получим отказ в доступе.
Посмотрим, как правильно настроить права:
IIS AppPool\ИмяПула или NetworkService).C:\Program Files\1cv8\8.3.XX.XXXX\bin).Разберем ситуацию, когда база была развернута как копия работающей системы. В современных версиях платформы 1С (начиная с 8.3.14) при запуске базы, помеченной как копия, включается автоматическая блокировка регламентных заданий и внешних ресурсов.
Хотя этот режим в первую очередь ограничивает исходящие запросы из 1С, он может косвенно влиять на работу HTTP-сервисов, если логика сервиса предполагает запуск фонового задания или обращение к заблокированным ресурсам. Рассмотрим, как убедиться, что проблема не в этом:
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="/ka_copy"
ib="Srvr="MyServer";Ref="Base2";">
<httpServices publishExtensionsByDefault="true" />
<standardURLs extensions="true" />
</point>
Обратите внимание на атрибут publishExtensionsByDefault="true". Если этот флаг отсутствует, ваши HTTP-сервисы, добавленные через расширения, не будут доступны извне, даже если сама база опубликована успешно. Также проверьте параметр extensions="true" в секции standardURLs.
Выясним, почему изменения иногда не вступают в силу сразу. IIS активно кэширует конфигурацию. Если вы изменили имя публикации в конфигураторе 1С или отредактировали файл default.vrd вручную, IIS может продолжать использовать старые дескрипторы.
Рассмотрим алгоритм правильного применения настроек:
World Wide Web Publishing Service.Подводя итог нашему анализу, можно составить чеклист для решения проблемы ошибки 401.5:
bin платформы 1С и файл wsisapi.dll.default.vrd включена публикация сервисов расширений (publishExtensionsByDefault="true").Соблюдение этих шагов позволит избежать большинства проблем при публикации баз 1С на веб-серверах и обеспечит стабильную работу ваших HTTP-интерфейсов, что станет основой для быстрой организации полноценного API. Например, стабильный веб-интерфейс крайне важен при организации интеграции 1С с маркетплейсами Ozon, Wildberries и Яндекс.Маркет.