Почему опубликованный на веб-сервере HTTP-сервис из расширения 1С не виден или не работает?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с платформой 1С:Предприятие версии 8.3.7 и выше, разработчики часто сталкиваются с необходимостью создания и публикации HTTP-сервисов не в основной конфигурации, а в расширениях. Это позволяет внедрять дополнительную функциональность, такую как интеграция с внешними системами или создание пользовательских API, не снимая основную конфигурацию с поддержки. Однако, при попытке публикации таких сервисов, пользователи могут обнаружить, что HTTP-сервисы из расширений не отображаются в стандартном диалоге публикации на веб-сервере в конфигураторе 1С, и, как следствие, не работают после публикации. Давайте разберем, почему это происходит и как правильно настроить публикацию.

В чем суть проблемы, или «куда делись мои HTTP-сервисы?»

Основная причина, по которой HTTP-сервисы, разработанные в расширениях, кажутся «невидимыми» при публикации, заключается в особенностях реализации платформы 1С:Предприятие. В отличие от HTTP-сервисов, созданных непосредственно в основной конфигурации, сервисы из расширений не отображаются в привычном списке, где вы выбираете, какие именно сервисы опубликовать. Это может ввести в заблуждение, поскольку создается впечатление, что система их просто не видит или игнорирует.

Например, пользователь мог создать простой HTTP-сервис типа "пинг" в расширении, который должен возвращать "OK TEST PROIDEN", но после публикации, даже при активной отладке, сервис остается недоступным. При этом технические условия публикации могут быть соблюдены: веб-сервер установлен (например, IIS x64), используется соответствующая 64-битная платформа 1С или, в некоторых случаях, 32-битная платформа из-за специфических требований к веб-расширениям. Тем не менее, без правильной настройки, HTTP-сервис не будет реагировать на запросы.

Два основных способа публикации HTTP-сервисов из расширений

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

  1. Метод 1: Автоматическая публикация всех сервисов расширений (рекомендуемый для большинства случаев)

    Наиболее простой и часто используемый способ публикации HTTP-сервисов из расширений — это установка специального флажка в диалоге публикации на веб-сервере. Этот метод идеально подходит, когда требуется опубликовать все HTTP-сервисы, содержащиеся в активных расширениях, без необходимости выбирать их по отдельности.

    Шаги по активации:

    1. Откройте конфигуратор 1С.
    2. Перейдите в меню "Администрирование" -> "Публикация на веб-сервере...".
    3. В открывшемся диалоге публикации найдите и установите флажок "Публиковать HTTP сервисы расширений по умолчанию" (Publish HTTP services of extensions by default).
    4. Нажмите кнопку "Опубликовать".

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

    В файле публикации default.vrd, который находится в каталоге публикации вашей информационной базы на веб-сервере, этот флажок соответствует атрибуту publishExtensionsByDefault="true" для элемента . Вот пример структуры, которую вы можете увидеть:

    
<httpServices publishExtensionsByDefault="true">
    ...
</httpServices>

    Рассмотрим пример простого HTTP-сервиса, который может быть реализован в вашем расширении для проверки его работоспособности:

    
// В модуле HTTP-сервиса расширения
Функция ObmenObmen(Запрос)
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(НСтр("ru = 'OK TEST PROIDEN'"));
    Возврат Ответ;
КонецФункции

    Если ваш сервис называется "Obmen" с методом "Obmen", и публикация находится по адресу http://srviq000:85/BPiq000/, то после успешной публикации с установленным флажком вы сможете проверить его, обратившись по URL, например: http://srviq000:85/BPiq000/hs/Obmen/Obmen. В ответ вы должны получить строку "OK TEST PROIDEN".

  2. Метод 2: Ручное управление публикацией через файл default.vrd

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

    Шаги по активации:

    1. Выполните первоначальную публикацию информационной базы на веб-сервере (если она еще не опубликована) любым способом, чтобы создать базовый файл default.vrd.
    2. Найдите файл default.vrd в каталоге, где размещена ваша информационная база на веб-сервере. Обычно это подкаталог внутри каталога веб-сервера (например, C:\inetpub\wwwroot\your_base_name\ для IIS).
    3. Откройте файл default.vrd любым текстовым редактором (например, Notepad++).
    4. Найдите секцию . Если вы использовали Метод 1, там может быть publishExtensionsByDefault="true". Вы можете удалить этот атрибут или установить его в "false", если хотите полностью контролировать сервисы вручную.
    5. Для каждого HTTP-сервиса из расширения, который вы хотите опубликовать, добавьте отдельную секцию в секцию . Структура такой секции аналогична той, что используется для сервисов основной конфигурации. Вам нужно будет указать имя сервиса и базовый URL.
    6. После внесения изменений в default.vrd, обязательно перезапустите веб-сервер (IIS или Apache), чтобы изменения вступили в силу. Без перезапуска веб-сервера новые настройки не будут применены.

    Пример структуры записи для HTTP-сервиса из расширения в файле default.vrd:

    
<httpServices publishExtensionsByDefault="false"> 
    <httpService
        name="MyExtensionService"
        rootUrl="hs/MyExtensionService/"
        enable="true"
        authentication="true"
        userName="WebUser"
        password="MyPassword"
    />
    <httpService
        name="Obmen"
        rootUrl="hs/Obmen/"
        enable="true"
    />
    <!-- Добавьте другие сервисы расширений по мере необходимости -->
</httpServices>

    Обратите внимание, что для HTTP-сервисов, реализованных непосредственно в расширении, атрибут fileName обычно не требуется, поскольку они встраиваются в общий контекст публикации. Достаточно указать name и rootUrl.

Почему HTTP-сервисы из расширений не отображаются в конфигураторе?

Мы выяснили, что HTTP-сервисы из расширений не появляются в списке публикации в конфигураторе. Это не ошибка, а задуманное поведение платформы 1С. В документации 1С:Предприятия прямо указано, что: "В отличие от HTTP-сервисов, созданных в основной конфигурации, установка в диалоге публикации флажка Публиковать HTTP сервисы расширений по умолчанию не позволяет выбирать для публикации конкретные сервисы расширений." Это означает, что для сервисов расширений либо все сразу (через флажок), либо ручное редактирование файла публикации. Разработчики 1С сделали такой выбор, чтобы упростить процесс интеграции и избежать необходимости постоянного обновления списков в GUI для динамически подключаемых расширений.

Настройка аутентификации для HTTP-сервисов из расширений

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

  1. Использование служебных пользователей и токенов доступа: Для внешних систем, которые будут обращаться к вашим HTTP-сервисам, рекомендуется создавать отдельных служебных пользователей в 1С с минимальными необходимыми правами доступа. Вместо передачи учетных данных при каждом запросе, внешняя система может сначала получить токен доступа (например, через отдельный HTTP-сервис аутентификации). Этот токен затем используется при каждом последующем вызове основного HTTP-сервиса. Токены обычно имеют ограниченный срок действия, что повышает безопасность.
  2. Проксирование через Nginx (или другой веб-сервер): Мы можем использовать Nginx (или Apache) в качестве прокси-сервера перед веб-сервером 1С. Nginx может быть настроен для подстановки заголовков авторизации (например, Authorization: Basic ...) при перенаправлении запросов к HTTP-сервисам 1С. Это позволяет скрыть учетные данные 1С от прямого доступа и централизованно управлять авторизацией на уровне прокси-сервера. Nginx также позволяет реализовать дополнительные механизмы безопасности, такие как ограничение доступа по IP-адресам или использование клиентских сертификатов.
  3. Настройка авторизации в самом HTTP-сервисе: Для максимальной гибкости вы можете реализовать собственные механизмы проверки авторизации непосредственно в коде вашего HTTP-сервиса 1С. Например, сервис может ожидать передачу специального токена или ключа в заголовках запроса или в теле запроса. После получения запроса, код сервиса проверяет валидность этого токена/ключа, и только в случае успеха продолжает выполнение логики.
  4. Аутентификация ОС на веб-сервере IIS: В диалоге публикации 1С есть опция, которая позволяет настроить аутентификацию операционной системы на веб-сервере IIS. Это может быть полезно в корпоративных средах, где пользователи уже аутентифицированы в домене Windows. Однако этот метод не всегда подходит для внешних интеграций.
  5. Разделение публикаций для разных сценариев: Для различных сценариев использования (например, одни сервисы без авторизации для внутреннего использования, другие с авторизацией для внешних систем) вы можете создать несколько публикаций одной и той же информационной базы в разных виртуальных каталогах на веб-сервере. Для публикаций, где авторизация не нужна, можно ограничить доступ по IP-адресам или прописать в default.vrd пользователя с минимальными правами, имеющего доступ только к конкретному сервису.

Хотя файл default.vrd позволяет указать логин и пароль пользователя 1С, для повышения безопасности и гибкости рекомендуется использовать альтернативные методы аутентификации, такие как проксирование через Nginx или аутентификация по токенам для внешних систем.

Важные аспекты и советы

При работе с HTTP-сервисами из расширений учитывайте следующие моменты, чтобы избежать распространенных проблем:

  1. Версия платформы 1С:Предприятие: Убедитесь, что вы используете платформу версии 8.3.7 или выше, так как HTTP-сервисы в расширениях появились именно с этой версии.
  2. Установка веб-расширений: При установке платформы 1С:Предприятие на сервер, убедитесь, что компоненты "Расширение веб-сервера" были установлены. Это критично для работы веб-сервисов. Проверьте, что версия платформы 1С, используемая для веб-сервера (например, x64), соответствует версии веб-сервера (например, IIS x64). Иногда могут возникать сложности с совместимостью, если сервер 64-битный, а платформа установлена 32-битная, хотя чаще это связано с неправильной настройкой пулов приложений IIS.
  3. Права администратора при публикации: Всегда выполняйте операцию публикации на веб-сервере из конфигуратора от имени пользователя с правами администратора на сервере, где установлен веб-сервер. Это предотвратит проблемы с записью файлов в каталоги веб-сервера.
  4. Перезапуск веб-сервера: После любого ручного редактирования файла default.vrd или изменения настроек публикации, обязательно перезапускайте веб-сервер (IIS, Apache) для применения изменений.
  5. Пути и регистр символов: Внимательно проверяйте URL-адреса, по которым вы пытаетесь получить доступ к HTTP-сервисам. Платформа 1С чувствительна к регистру символов в URL-путях. Например, /hs/Obmen/Obmen будет отличаться от /hs/obmen/obmen.
  6. Файлы публикации: Убедитесь, что в каталоге публикации вашей базы на веб-сервере присутствуют файлы *.wsdd и *.vrd. Эти файлы являются основными для описания структуры базы 1С и её HTTP-сервисов.

Таким образом, проблема с невидимостью HTTP-сервисов из расширений в конфигураторе — это не баг, а особенность платформы.

← На главную