При разработке интеграций часто возникает ситуация, когда обычные пользователи должны заходить в базу под своими учетными данными с вводом логина и пароля, а внешние системы (например, сайт или мобильное приложение) должны обращаться к HTTP-сервису автоматически. Если оставить настройки по умолчанию, то внешнему запросу придется либо передавать данные авторизации каждый раз, либо сталкиваться с окном выбора пользователя, что технически невозможно для автоматизированного POST запроса.
В этой статье мы разберем, как разделить эти потоки, используя несколько публикаций и тонкую настройку конфигурационных файлов веб-сервера.
Это наиболее надежный и распространенный метод. Его суть заключается в том, что одна и та же информационная база публикуется на веб-сервере дважды: в разные виртуальные каталоги. Рассмотрим этот процесс подробнее.
Для реализации этого способа выполним следующие шаги:
C:\inetpub\wwwroot\base_web для пользователей и C:\inetpub\wwwroot\base_api для сервисов).default.vrd.default.vrd, который предназначен для HTTP-сервисов, мы пропишем параметры авторизации непосредственно в строке соединения.Проанализируем структуру строки соединения ib в файле default.vrd. Нам необходимо добавить параметры usr (имя пользователя) и pwd (пароль). Пример настройки:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/base_api"
ib="File="C:\Bases\Trade";usr=web_user;pwd=password123;">
<httpServices>
<service name="ОбменССайтом" rootUrl="v1" publish="true" />
</httpServices>
</point>
В данном случае, при обращении к адресу http://server/base_api/hs/v1/... платформа автоматически авторизует сеанс под пользователем web_user. При этом основная публикация http://server/base_web останется без изменений и будет запрашивать пароль у обычных пользователей.
Если вы используете веб-сервер Apache, принцип разделения остается таким же, но настройка выполняется через конфигурационный файл httpd.conf. Выясним, как правильно прописать пути.
Нам необходимо создать два алиаса (Alias), которые будут указывать на разные каталоги с разными файлами default.vrd. В конфигурационном файле Apache это выглядит следующим образом:
Alias "/base_user" "C:/www/base_user/"
<Directory "C:/www/base_user/">
AllowOverride None
Options None
Require all granted
SetHandler 1c-application
ManagedApplicationDescriptor "C:/www/base_user/default.vrd"
</Directory>
Alias "/base_api" "C:/www/base_api/"
<Directory "C:/www/base_api/">
AllowOverride None
Options None
Require all granted
SetHandler 1c-application
ManagedApplicationDescriptor "C:/www/base_api/default.vrd"
</Directory>
Таким образом, мы получаем две независимые точки входа в одну и ту же базу 1С с разными правилами доступа.
Рассмотрим ситуацию, когда создавать вторую публикацию неудобно. Платформа 1С поддерживает стандарт Basic Authentication. Это означает, что внешняя система может передать логин и пароль прямо в заголовках HTTP запроса.
Для этого в POST запросе необходимо добавить заголовок Authorization. Значение заголовка формируется как строка Логин:Пароль, закодированная в формат Base64. Например, для пользователя admin с паролем 123 заголовок будет выглядеть так:
Authorization: Basic YWRtaW46MTIz
При получении такого запроса 1С автоматически попытается выполнить вход под указанными данными. Это позволяет использовать одну публикацию для всех целей, если вызывающая сторона умеет работать с заголовками.
При работе с HTTP-сервисами важно учитывать производительность. В файле default.vrd существуют атрибуты, которые помогут сделать работу сервиса стабильнее:
false, платформа перестанет предлагать стандартное диалоговое окно авторизации в браузере.POST запросов) рекомендуется настраивать пул, чтобы не тратить время на инициализацию нового сеанса при каждом обращении.Если вы выбрали путь анонимной публикации (с зашитым техническим пользователем в .vrd), крайне рекомендуется реализовать дополнительную проверку внутри самого метода 1С. Разберем, как это сделать.
Мы можем передавать в теле запроса или в кастомном заголовке специальный токен (ключ доступа). В коде метода HTTP-сервиса мы извлекаем этот токен и сравниваем его с эталоном, хранящимся в базе (например, в константе).
Функция УзелОбменаДаннымиPost(Запрос)
КлючДоступа = Запрос.Заголовки.Получить("X-Auth-Token");
Если КлючДоступа <> Константы.ТокенВнешнегоСервиса.Получить() Тогда
Ответ = Новый HTTPСервисОтвет(401); // Unauthorized
Ответ.УстановитьТелоИзСтроки("Неверный токен доступа");
Возврат Ответ;
КонецЕсли;
// Логика обработки запроса...
КонецФункции
Проанализируем важный аспект безопасности. Для пользователя, который будет указан в настройках default.vrd для HTTP-сервиса, необходимо создать минимальную роль. Никогда не используйте пользователя с полными правами для публикации сервисов.
В роли должны быть отмечены только два ключевых права:
Удаленный доступ (HTTP) для конкретного HTTP-сервиса.Это гарантирует, что даже если файл default.vrd с логином и паролем будет скомпрометирован, злоумышленник не сможет получить доступ к остальным данным системы.