Почему веб-сервисы 1С не публикуются на IIS или требуют авторизации?

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

Начальная проверка и перепроверка публикации

Прежде всего, давайте убедимся, что все базовые шаги по публикации выполнены корректно (в этом может помочь Публикатор 1С) и наш веб-сервер готов к работе с 1С.

1. Запуск конфигуратора от имени администратора: Мы всегда должны запускать конфигуратор 1С от имени администратора перед публикацией на веб-сервере. Это обеспечивает необходимые права для записи файлов и настройки IIS. Даже если конфигуратор пишет "Публикация обновлена", без прав администратора изменения могут не быть применены.
2. Проверка компонентов IIS: Убедитесь, что на сервере IIS установлены все необходимые компоненты. Помимо базовых, нам критически важны:
   • Расширения ISAPI
   • Фильтры ISAPI

   Эти компоненты находятся в разделе "Разработка приложений" (Application Development) при добавлении ролей и компонентов IIS. Мы должны проверить их наличие.

3. Модуль расширения веб-сервера 1С: При установке платформы 1С:Предприятие необходимо убедиться, что был выбран компонент "Модули расширения веб-сервера". Если мы используем 64-разрядную платформу (как в нашем случае 1С8.3 x64), то нам нужен именно 64-разрядный модуль расширения веб-сервера. Если модуль не установлен, публикация не будет работать корректно.
4. Перезапуск IIS: После любых изменений в настройках IIS или после публикации из 1С, нам следует перезапустить службы IIS или весь веб-сервер. Это можно сделать через консоль "Диспетчер служб IIS" или командой iisreset в командной строке, запущенной от имени администратора. Для тех, кто предпочитает альтернативные веб-серверы, существует автоматизированный установщик Apache.

Настройка пула приложений IIS

Корректная работа веб-сервисов 1С во многом зависит от правильной настройки пула приложений (Application Pool), который обслуживает наше опубликованное приложение.

1. Разрядность пула приложений: Если мы используем 64-разрядную платформу 1С с 64-разрядным модулем wsisapi.dll, то параметр "Разрешены 32-разрядные приложения" (Enable 32-bit Applications) в расширенных настройках пула приложений (например, DefaultAppPool или созданного для 1С) должен быть установлен в False. Если же по какой-то причине мы используем 32-разрядный модуль на 64-разрядной ОС, то этот параметр должен быть установлен в True. В нашем случае, с 1С8.3 x64, мы должны выставить False.
2. Режим управляемого кода: Мы рекомендуем настроить пул приложений на "Без управляемого кода" (No Managed Code) и отключить поддержку среды .NET, если она не требуется для других приложений в этом пуле. Это предотвратит возможные конфликты и лишние накладные расходы.
3. Режим конвейера управляемого кода: В большинстве случаев для современных приложений режим конвейера управляемого кода (Managed Pipeline Mode) пула приложений должен быть установлен в "Integrated" (интегрированный). В некоторых старых сценариях или для совместимости может использоваться "Classic", но для 1С на текущих версиях IIS обычно подходит "Integrated".

Настройка сопоставления обработчиков (Handler Mappings) в IIS

Чтобы IIS понимал, как обрабатывать запросы к файлам 1С (например, *.1cws для веб-сервисов), необходимо настроить сопоставления обработчиков.

1. Добавление сопоставлений: Мы должны убедиться, что для расширений *.1cws и *.1crs (для HTTP-сервисов) добавлены отдельные сопоставления обработчиков. Эти сопоставления должны указывать на файл wsisapi.dll вашей версии платформы 1С. Пример пути: C:\Program Files\1cv8\8.3.18.1334\bin\wsisapi.dll (путь должен соответствовать вашей установленной версии).
2. Разрешение выполнения: Для этих обработчиков критически важно разрешить выполнение (Execute) скриптов и приложений. Мы можем проверить это в "Ограничениях запросов" (Request Restrictions) на вкладке "Доступ" (Access) или в "Edit Feature Permissions" для каждого обработчика.
3. Актуализация пути: Важно, чтобы путь к wsisapi.dll был корректным и соответствовал установленной версии платформы 1С. При обновлении платформы этот путь может измениться, и его необходимо актуализировать вручную в настройках IIS или переопубликовать базу из конфигуратора, чтобы 1С обновил эти настройки.

Права доступа к файлам и папкам

Некорректные права доступа — одна из наиболее частых причин проблем с публикацией и работой 1С на IIS.

1. Папки 1С и IIS: Мы уже предоставили полный доступ для пользователей IUSR и группы IIS_IUSRS для папок C:\Program Files\1cv8 и C:\inetpub\wwwroot. Это хороший старт.
2. Доступ к информационной базе: Мы должны дополнительно предоставить группе IIS_IUSRS права на чтение и выполнение для каталога с информационной базой 1С. Если база является файловой, то требуются также права на изменение для этой папки, поскольку веб-серверу необходимо будет записывать данные в файлы базы. Если база клиент-серверная, то доступ к файлам на сервере СУБД будет осуществлять сервер 1С, но все равно, временные файлы могут создаваться, и дополнительные права не помешают.
3. Пользователь, под которым работает пул приложений: По умолчанию пул приложений работает под учетной записью ApplicationPoolIdentity, которая является частью группы IIS_IUSRS. Поэтому предоставление прав IIS_IUSRS обычно достаточно. Если пул приложений настроен на работу под другой учетной записью (например, доменной), то именно этой учетной записи должны быть предоставлены все необходимые права.

Файл default.vrd и его содержимое

Файл default.vrd является ключевым для публикации 1С на веб-сервере. Он описывает, какие сервисы и каким образом опубликованы.

В нашем случае, содержимое default.vrd выглядит следующим образом:

[vrd]

    
    
    
        
        
        
        
        
        
        
        
        
        
        
        
        
        
    
    
        
        
    

Проанализируем этот файл:

1. Пространство имен http://v8.1c.ru/8.2/virtual-resource-system: Несмотря на то, что используется платформа 8.3, в файле default.vrd может быть указано пространство имен 8.2. Это нормальное поведение 1С, поскольку сама структура файла default.vrd описана в документации для платформы 8.3 и является универсальной. Это не является ошибкой.
2. Блок : Мы видим, что в этом блоке перечислены множество веб-сервисов, включая InterfaceVersion, EnterpriseDataExchange и другие. Это подтверждает, что веб-сервисы фактически опубликованы из 1С и их описание присутствует в конфигурационном файле — для этого подойдёт организация обмена через веб-сервисы и COM.
3. Атрибут base="/Demo": Этот атрибут указывает базовый URL для нашего опубликованного приложения, в данном случае /Demo. Это важная часть для формирования корректных адресов.
4. Строка подключения к базе ib="Srvr="1CDEV";Ref="dev2";": Убедимся, что параметры сервера 1С (Srvr) и имя информационной базы (Ref) указаны верно. Ошибки здесь могут привести к тому, что 1С-сервер не сможет подключиться к базе.

Доступ к веб-сервисам и проблемы с авторизацией

Когда мы убедились, что приложение опубликовано и файл default.vrd корректен, следующим шагом будет проверка доступности веб-сервисов и решение вопросов с авторизацией.

1. Корректный URL для веб-сервисов: Изначально, возможно, мы использовали неверный формат URL для доступа к веб-сервисам. Если основное приложение 1С доступно по http://localhost/Demo/ru_RU/, то веб-сервисы обычно доступны по следующему пути:

   http://localhost/Demo/ws/ИмяВебСервиса.1cws

   Например, для веб-сервиса InterfaceVersion корректным адресом будет:

   http://localhost/Demo/ws/InterfaceVersion.1cws

   Чтобы получить WSDL-описание веб-сервиса, которое является признаком его доступности, мы можем добавить ?wsdl в конец адреса:

   http://localhost/Demo/ws/InterfaceVersion.1cws?wsdl

   Если по этому адресу мы получаем XML-файл с описанием сервиса (WSDL), значит, веб-сервис успешно опубликован и доступен, и проблема перемещается в плоскость авторизации.

2. Настройка анонимной авторизации в IIS: Если нам нужен доступ к веб-сервисам без авторизации (например, для внутреннего использования в локальной сети), мы должны проверить и настроить анонимную проверку подлинности (Anonymous Authentication) в IIS.
   • В "Диспетчере служб IIS" мы переходим к нашему сайту или приложению (виртуальному каталогу).
   • В разделе "Проверка подлинности" (Authentication) мы должны убедиться, что Анонимная проверка подлинности (Anonymous Authentication) включена. Если она отключена, мы включаем ее.
   • Также важно проверить, что другие виды проверки подлинности (например, Windows Authentication) отключены, если они не нужны, чтобы избежать конфликтов.
3. Пользователь в default.vrd: В файле default.vrd можно указать пользователя и пароль для подключения к информационной базе. Например:
   Скопировать код

   
   ib="Srvr="1CDEV";Ref="dev2";Usr="ВебПользователь";Pwd="Пароль";"
   

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

4. Проблемы с делегированием (если серверы разные): Если веб-сервер IIS и сервер 1С:Предприятия находятся на разных машинах, а мы используем Windows-аутентификацию, то могут возникнуть проблемы с делегированием прав в Active Directory. В таких случаях требуется настройка Kerberos-делегирования, что является более сложной задачей и выходит за рамки простой публикации. Для большинства случаев анонимный доступ через IIS с последующей проверкой прав в 1С или использование базовой аутентификации является более простым решением.

Дополнительные рекомендации и диагностика

Если после всех этих шагов проблема остается, мы можем прибегнуть к дополнительным инструментам IIS.

1. Журналы HTTP (HTTP Logging): Мы можем включить и анализировать журналы HTTP в IIS. В них будут записываться все запросы к веб-серверу, ответы, коды ошибок и другая полезная информация, которая может указать на причину проблемы — поможет анализатор и логгер HTTP-запросов для 1С.
2. Монитор запросов (Request Monitor): Этот инструмент в IIS позволяет в реальном времени отслеживать активные и завершенные запросы, их длительность, статус и используемые обработчики. Это может помочь определить, на каком этапе происходит сбой.
3. Пустая конфигурация: Убедитесь, что конфигурация 1С, которую мы пытаемся опубликовать, не является пустой. Веб-сервисы и HTTP-сервисы должны быть созданы и опубликованы в конфигураторе.
4. Безопасность: Для обеспечения максимальной безопасности мы всегда рекомендуем использовать протокол HTTPS вместо HTTP для опубликованных веб-сервисов, особенно если они доступны извне локальной сети.

Следуя этим шагам, мы можем системно подойти к диагностике и устранению проблем при публикации веб-сервисов 1С на IIS, начиная от базовой доступности и заканчивая тонкой настройкой авторизации.