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

← На главную

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

Разберем суть проблемы и структуру файла публикации

Когда мы публикуем информационную базу на веб-сервере (Apache или IIS), создается специальный конфигурационный файл с расширением .vrd (Virtual Resource Descriptor). Этот файл является «инструкцией» для веб-сервера, которая объясняет, как именно взаимодействовать с 1С. По умолчанию стандартная публикация открывает доступ ко всему: и к интерфейсу базы, и к программным интерфейсам.

Многие разработчики ошибочно полагают, что для «скрытия» базы достаточно убрать строку соединения ib из настроек. Однако, как показывает практика, без параметра ib (который указывает путь к базе) веб-сервер просто не поймет, к какому источнику данных перенаправлять входящие HTTP-запросы. Поэтому наша задача — сохранить связь с базой, но программно запретить запуск клиентских приложений.

Способ 1. Настройка через Конфигуратор (визуальный метод)

Рассмотрим самый простой и безопасный способ настройки через стандартный интерфейс 1С. Это позволит избежать синтаксических ошибок в XML-структуре файла.

Откроем Конфигуратор от имени администратора.
Перейдем в меню Администрирование — Публикация на веб-сервере.
На вкладке Основные снимем флажок Публиковать доступ для клиентских приложений. Также рекомендуем снять флажок Публиковать стандартный интерфейс OData, если вы его не используете.
Перейдем на вкладку HTTP сервисы. Здесь нужно убедиться, что флажок Публиковать HTTP сервисы по умолчанию установлен, либо выбраны конкретные сервисы из списка ниже.
Если ваши сервисы находятся в расширениях, обязательно проверьте флажок Публиковать HTTP сервисы расширений по умолчанию.
Нажмем кнопку Опубликовать.

После этих действий система автоматически изменит файл default.vrd. Теперь при попытке зайти по адресу публикации через браузер пользователь увидит ошибку доступа, но при этом запросы к вашим сервисам по пути .../hs/ИмяСервиса/ будут успешно обрабатываться. Для проверки доступности методов и корректности авторизации можно использовать обработку для тестирования HTTP-сервисов.

Способ 2. Ручное редактирование файла .vrd

Иногда требуется настроить публикацию на сервере, где не установлен Конфигуратор, или нужно внести специфические правки. Проанализируем структуру «правильного» файла .vrd, который решает нашу задачу.

Ключевым моментом здесь является атрибут enable в корневом элементе point. Если установить его в значение false, то доступ через веб-клиент и тонкий клиент будет закрыт. При этом внутри секции httpServices мы можем точечно включить нужные нам сервисы.

Посмотрим на пример структуры такого файла:


<?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="/MyService"
       ib="Srvr=&quot;MyServer&quot;;Ref=&quot;MyBase&quot;;"
       enable="false">
    <httpServices publishByDefault="false">
        <service name="MyCustomService"
                rootUrl="v1"
                enable="true"
                reuseSessions="autouse"
                sessionMaxAge="20"
                poolSize="10"
                poolTimeout="5"/>
    </httpServices>
</point>

В данном примере мы видим, что глобальный параметр enable="false" блокирует вход в базу, но для сервиса MyCustomService установлено enable="true", что делает его доступным для внешних вызовов.

Автоматизация авторизации для HTTP-сервисов

Часто возникает вопрос: как указать логин и пароль только для сервиса, чтобы внешняя система не передавала их в каждом запросе (хотя передача заголовка Authorization является более правильным подходом с точки зрения безопасности). В платформе 1С существует возможность прописать учетные данные прямо в файле .vrd.

Для этого в корневой тег point добавляются атрибуты usr и pwd. Важный момент: не пытайтесь переносить эти параметры внутрь секции service, так как схема XML этого не предусматривает, и публикация станет невалидной. Параметры должны быть указаны именно на уровне всей публикации.

Пример заголовка с авторизацией:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/MyService"
       ib="File=&quot;C:\Base1C&quot;;"
       enable="false"
       usr="ServiceRobot"
       pwd="StrongPassword">

Внимание: помните, что пароль в этом файле хранится в открытом виде. Если злоумышленник получит доступ к файловой системе сервера, он узнает пароль. Рекомендуется использовать для этих целей пользователя с минимально необходимыми правами (только право на использование конкретного HTTP-сервиса). Для организации более безопасного доступа по токенам и формирования параметров для .vrd подойдёт обработка для создания JWT-токенов и настройки публикации.

Повышение безопасности на уровне веб-сервера

Рассмотрим ситуацию, когда мы хотим сделать базу еще более «невидимой». Даже при enable="false" веб-сервер может выдавать служебную информацию 1С. Мы можем настроить ограничения на уровне самого программного обеспечения веб-сервера (Apache или IIS).

Для сервера Apache: мы можем использовать файл .htaccess или настройки виртуального хоста, чтобы разрешить доступ только к URL, содержащим путь /hs/. Выясним, как это выглядит на практике:


RewriteEngine On
RewriteCond %{REQUEST_URI} !^/MyBase/hs/.*$
RewriteRule ^.*$ - [F]

Это правило вернет ошибку 403 (Forbidden) любому, кто попытается обратиться к корню публикации или любым другим ресурсам, кроме наших HTTP-сервисов.

Для сервера IIS: используем модуль URL Rewrite. Создаем правило типа Request Blocking, которое будет отклонять все запросы, если путь не соответствует паттерну .*/hs/.*.

Оптимизация работы сервисов: параметр allowFullSlowContext

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

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

Подведем итоги

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

Оставить строку ib в файле публикации для связи с данными.
Установить глобальный запрет доступа через enable="false".
Точечно включить нужные сервисы в секции httpServices.
При необходимости настроить автоматическую авторизацию через атрибуты usr и pwd.

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