Как настроить HTTP-сервис 1С без авторизации, сохранив вход по паролю для веб-клиента?

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

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

Способ 1: Две разные публикации (Рекомендуемый)

Самый надежный и понятный способ разделить сценарии использования — создать две независимые публикации одной и той же информационной базы на веб-сервере. Одна публикация будет служить для входа живых пользователей (с запросом пароля), а вторая — исключительно для HTTP-сервисов (с жестко прописанным техническим пользователем).

Рассмотрим алгоритм действий:

1. Создайте в базе 1С отдельного пользователя для сервиса (например, Robot_Http). Обязательно ограничьте его права, оставив доступ только к нужному HTTP-сервису, и задайте сложный пароль.
2. На веб-сервере создайте вторую папку для новой публикации (например, скопируйте папку существующей публикации и назовите её api или service).
3. Настройте веб-сервер (IIS или Apache) так, чтобы он воспринимал новую папку как приложение.
4. Отредактируйте файл default.vrd во второй папке, добавив в строку подключения логин и пароль технического пользователя.

Разберем структуру файла default.vrd. Нам необходимо изменить атрибут ib (Information Base) и добавить туда параметры usr и pwd. Также важно изменить параметр base, чтобы он соответствовал новому имени публикации.

Пример стандартного файла:

<?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="/base_user"
       ib="Srvr="localhost";Ref="MyBase";">
    <standardOdata enable="false"
                   reuseSessions="autouse"
                   sessionMaxAge="20"
                   poolSize="10"
                   poolTimeout="5"/>
</point>

Пример файла для сервиса (без авторизации):

<?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="/base_service"
       ib="Srvr="localhost";Ref="MyBase";Usr="Robot_Http";Pwd="DifficultPass123";">
    <standardOdata enable="false"
                   reuseSessions="autouse"
                   sessionMaxAge="20"
                   poolSize="10"
                   poolTimeout="5"/>
</point>

Обратите внимание: мы изменили base="/base_service" и добавили учетные данные в атрибут ib. Теперь при обращении по адресу http://server/base_service/... вход будет выполнен автоматически под пользователем Robot_Http.

Важно: При ручном редактировании файла default.vrd необходимо соблюдать правила XML. Если в пароле или имени пользователя есть спецсимволы, их нужно экранировать (см. раздел "Тонкости синтаксиса" ниже).

Способ 2: Basic Authorization в заголовках запроса

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

Клиент (внешнее приложение, инструменты тестирования http сервисов, браузер) должен добавить к своему запросу заголовок Authorization — так работает REST API для интеграции внешних систем с 1С.

Формат заголовка (включая Bearer токен в 1С:Шине):

Authorization: Basic <СтрокаBase64>

Где <СтрокаBase64> — это закодированная в формат Base64 строка вида Логин:Пароль.

Пример:

1. Логин: User1
2. Пароль: 555
3. Строка для кодирования: User1:555
4. Результат Base64: VXNlcjE6NTU1
5. Итоговый заголовок: Authorization: Basic VXNlcjE6NTU1

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

Способ 3: Проксирование и подмена заголовков на веб-сервере

Этот метод позволяет совместить плюсы первого и второго способов: у вас остается одна база, но для определенных URL веб-сервер сам подставляет логин и пароль. Клиент обращается к сервису без пароля, а веб-сервер "притворяется", что пароль был введен.

Настройка для Apache

Для реализации потребуется включить модули mod_headers, mod_rewrite, mod_proxy. В конфигурационный файл Apache (httpd.conf или конфиг виртуального хоста) добавляются следующие строки:

LoadModule headers_module modules/mod_headers.so
# Другие модули...

<Location /MyBase/hs/myservice>
    # Устанавливаем заголовок авторизации принудительно для конкретного пути
    RequestHeader set Authorization "Basic dGаfaG5vazo3Nk12Zmli"
</Location>

Здесь dGаfaG5vazo3Nk12Zmli — это закодированные в Base64 логин и пароль технического пользователя. Теперь при запросе к /MyBase/hs/myservice Apache сам добавит нужный заголовок, и 1С пустит запрос без лишних вопросов.

Настройка для IIS (URL Rewrite)

В IIS для этого используется модуль URL Rewrite. Необходимо создать правило (Inbound Rule), которое для определенного паттерна URL будет устанавливать серверную переменную.

1. Откройте настройки сайта в IIS Manager.
2. Зайдите в "URL Rewrite".
3. Создайте правило, которое отлавливает запросы к вашему HTTP-сервису.
4. В действиях (Actions) выберите изменение серверных переменных.
5. Установите переменную HTTP_AUTHORIZATION в значение Basic <ВашBase64>.

Этот способ безопаснее хранения пароля в default.vrd, так как конфигурация веб-сервера обычно лучше защищена от прямого скачивания.

Тонкости синтаксиса default.vrd и типичные ошибки

При ручном редактировании файла публикации (Способ 1) пользователи часто сталкиваются с ошибкой Ошибка разбора XML или EntityRef: expecting ';'. Это происходит из-за некорректного использования кавычек внутри XML-атрибутов.

Строка подключения ib сама по себе содержит кавычки (например, Ref="Base"). Когда мы помещаем её внутрь XML-атрибута ib="...", внутренние кавычки нужно заменять на спецсимволы (экранировать).

Неправильно:

ib="Srvr="localhost";Ref="Base";Usr="Admin";Pwd="123";"

Здесь структура XML нарушается, так как парсер видит конец атрибута после Srvr=.

Правильно (с экранированием):

ib="Srvr="localhost";Ref="Base";Usr="Admin";Pwd="123";"

Используйте следующие замены:

• " (двойная кавычка) → "
• ' (одинарная кавычка) → '
• & (амперсанд) → &
• < (меньше) → <
• > (больше) → >

Если вы редактируете файл вручную, внимательно следите за тем, чтобы все открытые кавычки были закрыты, а все спецсимволы — заменены на сущности XML.

Заключение и рекомендации по безопасности

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

Несколько советов по безопасности:

1. Никогда не используйте для HTTP-сервисов пользователей с полными правами или администраторов. Создайте роль с доступом только к конкретному HTTP-сервису.
2. Если используете Способ 1, защитите файл default.vrd от скачивания настройками веб-сервера (в IIS это обычно работает по умолчанию через Request Filtering для скрытых сегментов, в Apache используйте <FilesMatch>).
3. При использовании проксирования (Способ 3) убедитесь, что доступ к "беспарольному" URL ограничен по IP-адресам (например, разрешен только с IP вашего сайта или приложения), чтобы злоумышленники не могли воспользоваться подставленным паролем — для этого подойдёт реализация интернет-магазина в Telegram через Webhook.