Как настроить доступ к HTTP-сервису 1С без ввода пароля и восстановить отладку после изменения сети

← На главную

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

Способ 1. Указание пользователя по умолчанию в файле default.vrd (Быстрый метод)

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

Для реализации этого метода откроем файл default.vrd, расположенный в каталоге публикации базы на веб-сервере (например, C:\inetpub\wwwroot\НашаБаза\). Найдем строку подключения к базе данных ib и допишем в нее параметры Usr и Pwd:


<?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="/BaseName"
       ib="Srvr="MyServer";Ref="MyBase";Usr=WebhookUser;Pwd=StrongPassword123;">
</point>

Важное предупреждение: данный способ является крайне небезопасным! Прописав учетные данные в общую строку подключения, мы открываем доступ к нашей базе под этой учетной записью для любого внешнего запроса. Злоумышленники смогут без авторизации зайти в базу через веб-клиент или выгрузить данные через OData-интерфейс. Поэтому мы настоятельно рекомендуем использовать более безопасные альтернативы, описанные ниже.

Способ 2. Создание изолированной публикации для вебхуков (Безопасный метод)

Чтобы защитить базу данных от несанкционированного доступа, мы можем настроить изолированную публикацию. Вместо изменения основного файла публикации создадим вторую публикацию базы на веб-сервере в другой виртуальный каталог (например, /webhook_receiver).

Разберем по шагам схему настройки изолированной публикации:

Создадим отдельный физический каталог на сервере (например, C:\inetpub\wwwroot\webhook_receiver\).
Опубликуем базу данных в этот каталог под новым именем.
В созданном файле default.vrd принудительно отключим все веб-клиенты, OData-интерфейсы, тонкие клиенты и сторонние веб-сервисы с помощью параметра enable="false".
Разрешим работу только одного конкретного HTTP-сервиса, обрабатывающего вебхуки.
В строке подключения пропишем служебного пользователя 1С, у которого в конфигураторе настроены минимально возможные права (только на чтение и запись документов, связанных с вебхуками).

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


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/webhook_receiver"
       ib="Srvr="MyServer";Ref="MyBase";Usr=ServiceUser;Pwd=ServicePassword;">
    <ws enable="false" />
    <httpServices publishByDefault="false">
        <service name="WebhookReceiver" alias="receiver" enable="true" />
    </httpServices>
    <standardOdata enable="false" />
</point>

Благодаря параметру publishByDefault="false" и отключению стандартных интерфейсов, любой злоумышленник, попытавшийся открыть веб-клиент по этому адресу или обратиться к другим сервисам, получит ошибку авторизации. Доступ останется открытым исключительно для одного HTTP-сервиса.

Способ 3. Передача авторизационных данных на стороне отправителя

Проанализируем ситуацию, когда внешняя система позволяет гибко настраивать отправляемые HTTP-запросы. Вместо настройки анонимного доступа на стороне 1С, мы можем передавать параметры авторизации в самом запросе. Большинство современных систем поддерживают базовую HTTP-авторизацию (Basic Authentication).

Если мы отправляем вебхук программно, например, с использованием утилиты Curl в PHP-приложении, мы можем передать логин и пароль в заголовках запроса. Разберем пример реализации:


curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);       
curl_setopt($ch, CURLOPT_USERPWD, $userLogin . ":" . $userPass);

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

Способ 4. Ограничение доступа по IP-адресам на веб-сервере

Выясним, как дополнительно обезопасить анонимный HTTP-сервис. Если внешняя система отправляет вебхуки со строго определенных серверов, отличной практикой будет ограничение пула входящих IP-адресов на уровне веб-сервера IIS или Apache.

В диспетчере служб IIS выберем наш виртуальный каталог вебхука и настроим правила:

Перейдем в раздел "Ограничения IP-адресов и доменов".
Добавим разрешающие правила для конкретных IP-адресов или подсетей внешней системы (например, серверов CRM-системы).
Для всех остальных неуказанных адресов настроим запрет доступа.

При такой схеме неавторизованные запросы от злоумышленников будут блокироваться веб-сервером на подлете (ошибка 403 Forbidden), даже не доходя до СУБД и сервера приложений 1С.

Способ 5. Использование файла .1cws (для Web-сервисов)

Если интеграция построена на базе SOAP Web-сервисов, мы можем настроить авторизацию точечно с помощью создания файла описания веб-сервиса с расширением .1cws. Рассмотрим структуру такого файла:


<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
         name="WebhookWebService"
         connectString="Srvr="MyServer";Ref="MyBase";usr="WebServiceUser";pwd="Pass123""/>

Важная деталь: при использовании данного метода необходимо корректно указывать пути обращения к сервису, исключая стандартные пути публикаций /ws или /hs, обращаясь напрямую к файлу .1cws на веб-сервере.

Перейдем ко второй части нашего разбора. Что делать, если после успешной настройки вебхуков и последующей перезагрузки сервера (или изменения параметров сетевой карты) отладка HTTP-сервиса перестала работать?

Устранение проблем с отладкой HTTP-сервисов после смены сети

Рассмотрим по шагам основные причины сбоя отладки 1С на веб-сервере и способы их оперативного решения.

Шаг 1. Сетевой профиль Брандмауэра Windows

При изменении параметров сетевого адаптера или смене IP-адреса операционная система Windows часто сбрасывает категорию сетевого подключения с "Частной" (Private) на "Общественную" (Public). По умолчанию брандмауэр блокирует любые входящие сетевые подключения для общественных сетей.

Решим эту проблему:

Откроем Брандмауэр Windows в панели управления.
Убедимся, что сетевой профиль настроен как "Частная сеть" или "Доменная сеть".
Если изменить профиль невозможно, вручную создадим правило для входящих подключений, разрешающее работу портов отладки 1С (диапазон TCP портов 1560-1591).

Шаг 2. Проверка IP-адреса отладки в файле default.vrd

Для отладки HTTP-сервисов в конфигурационном файле публикации default.vrd используется специальный тег <debug>. Посмотрим на его структуру:

<debug enable="true" protocol="tcp" url="tcp://192.168.1.50:1560" />

Если у компьютера разработчика, на котором запущен Конфигуратор 1С, изменился локальный IP-адрес, то указанный в параметре url адрес становится недействительным. Веб-сервер пытается отправить информацию отладчику на старый адрес, и точка останова не срабатывает. Обновите IP-адрес в параметре url на актуальный и обязательно перезапустите веб-сервер IIS/Apache.

Шаг 3. Запуск службы сервера 1С в режиме отладки

При перезагрузке операционной системы Windows служба сервера приложений "Агент сервера 1С:Предприятие" могла запуститься без ключа отладки. Системные администраторы часто включают этот ключ временно, забывая зафиксировать изменения.

Убедимся, что отладка на сервере активна:

Запустим редактор реестра regedit.
Перейдем по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent....
Найдем параметр ImagePath и проверим, присутствует ли в конце строки параметр -debug.
Если его нет, добавим ключ -debug в конец строки через пробел и перезапустим службу сервера 1С.

Шаг 4. Сброс кэша DNS

Если в настройках отладки мы используем имя хоста компьютера вместо IP-адреса, старые сетевые привязки могут остаться в кэше разрешения имен. Для сброса кэша DNS откроем командную строку от имени администратора и выполним следующую команду:

ipconfig /flushdns

Шаг 5. Автоматическое подключение в Конфигураторе

Убедимся, что сам Конфигуратор настроен на перехват фоновых заданий и внешних вызовов. В меню Конфигуратора перейдем в "Отладка" -> "Подключение..." -> "Настройка автоматического подключения". Убедимся, что флажки напротив пунктов "HTTP-сервисы" и "Web-сервисы" установлены. При необходимости в параметрах отладки Конфигуратора попробуем переключить протокол отладки с TCP/IP на HTTP.

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