В телеграм-канале INFOSTART Enterprise есть еженедельная рубрика «Вопрос/Ответ». Мы предлагаем подписчикам задавать любые вопросы по работе с конфигурациями 1С и стараемся давать полезные ответы.
На этот раз поговорим об автономном сервере и http-авторизации: разбирается в теме и отвечает на вопрос ведущий 1C-разработчик ИТ-лаборатории Инфостарт Александр Кунташов.
Вопрос
Есть ли возможность в 1С автономном сервере использовать HTTPзапросы расширений конфигурации и прописывать пользователя, под которым данные HTTPзапросы будут выполняться? На Apache реализовать через расширение HTTPзапрос не проблема, но раз у нас импортозамещение, хотелось бы использовать функции 1С автономного сервера вместо Apache.
Ответ
Если я правильно понял по контексту, тут вопрос не про возможность использовать объект HTTPЗапрос в базе, работающей под управлением автономного сервера, а про возможность публикации для этой базы HTTP-cервиса, реализованного в установленном в этой ИБ расширении.
Если вопрос про первое — то автономный сервер не имеет ограничений с точки зрения объектной модели, предоставляемой платформой 1С:Предприятие 8, и код, использующий объект HTTPЗапрос, будет прекрасно исполняться и под управлением автономного сервера.
Но мне кажется, вопрос был именно про http-сервисы, точнее тут даже целых два технических вопроса:
- В1. Можно ли для информационной базы (ИБ), работающей под управлением автономного сервера, опубликовать http-сервис, реализованный в расширении, установленном в эту ИБ?
- В2. Можно ли вызвать методы http-сервиса, опубликованного для ИБ, работающей под управлением автономного сервера, без необходимости на стороне клиента указывать логин и пароль (без basic-авторизации)?
Давайте попробуем разобраться и ответить на них.
В1: Можно ли при помощи автономного сервера опубликовать http-сервис из расширения?
TL;DR Да, можно.
По умолчанию, как и в случае с полноценным сервером 1С, http- и web-сервисы из расширений не публикуются автоматически, их нужно публиковать явно, равно как приходится это делать и при использовании веб-сервера. Если этого не сделать, при попытке обращения к http-сервису мы ожидаемо получим 503-ю ошибку:
Публикация http-сервиса на автономном сервере осуществляется при помощи конфигурационного yaml-файла. Его можно создать вручную, опираясь на примеры и документацию, либо сгенерировать при помощи утилиты ibcmd на основании данных ИБ уже опубликованной "классическим" способом (default.vrd).
Ручная настройка конфигурации для публикации http-сервиса
Допустим, у нас есть информационная база с расширением МойСервис, в котором реализован одноименный http-сервис c корневым URL myservice и единственным методом ping, возвращающим текстовую строку pong
Для публикации этого сервиса для ИБ под управлением автономного сервера нужно создать конфигурационный файл, назовем его publication.yaml, следующего содержания:
# publication.yaml
http:
- base: /
http-services:
service:
- name: МойСервис
root: myservice
publish: true
Как мы видим, имена свойств этого файла соответствуют атрибутам описания веб-сервиса в vrd-файле. Подробнее о них можно прочитать в документации.
Допустим, наша ИБ файловая и размещена в каталоге C:\Bases1C\InfoBase, в этом случае запуск автономного сервера для этой ИБ с публикацией нашего http-сервиса будет выглядеть так:
ibsrv --db-path="C:\Bases1C\InfoBase" --config="C:\Bases1C\publication.yml"
После запуска автономного сервера этой командой, наш метод ping мы сможем «дернуть», перейдя в браузере по ссылке:
http://localhost:8314/hs/myservice/ping
Конвертация настроек публикации http-сервиса из файла default.vrd
Второй способ, который мы выше упоминали — сгенерировать конфигурационный файл на основе уже существующей публикации в виде файла default.vrd.
Делается это командой ibcmd server config import:
ibcmd server config import --cluster-data="C:\srvinfo" --name=mybase --publication="C:\www\mybase\default.vrd" --out="C:\Bases1C\puclication.yaml"
В аргументах команды, как видно, нужно указать каталог с данными кластера сервера 1С, где опубликована база (аргумент --cluster-data), имя этой базы в кластере (аргумент --name) и путь к default.vrd (--publication). В аргументе --out указывается путь к файлу, в который будет сохранена конфигурация для автономного сервера.
Далее полученный файл можно использовать для запуска этой ИБ под управлением автономного сервера, либо как шаблон для создания файлов конфигурации для других баз.
Этот способ работает только для информационных баз, зарегистрированных в кластере серверов 1С:Предприятия, файловые базы командой ibcmd server config import не поддерживаются.
Подробнее разные примеры создания конфигурационного файла описаны в официальной документации.
В2. Можно ли вызвать методы http-сервиса, опубликованного на автономном сервере, без Basic-авторизации?
TL;DR Да, если использовать промежуточный реверс-прокси. Нет, если ограничиться только штатными возможностями автономного сервера. По крайней мере, я такой возможности не нашел — напишите в комментариях, если я вдруг не прав и что-то упустил.
Почему штатно не работает, и как можно попытаться обойти
В default.vrd есть возможность указать имя пользователя и пароль, под которыми расширение для веб-сервера подключается к ИБ, в строке соединения с базой данных. Но при импорте этих параметров при помощи ibcmd эта строка соединения игнорируется и не переносится, и об этом явно написано в документации:
Следует помнить, что механизм импорта файла публикации игнорирует командную строку доступа к информационной базе, которая указана в атрибуте ib элемента point файла default.vrd. Пользователь, выполняющий импорт, должен осмысленно указывать параметры импортируемой базы и файла публикации.
Да и в принципе, в описании конфигурационного файла автономного сервера свойств для указания имени пользователя и пароля нет (см. справку).
Поэтому для использования http-сервисов (равно как и web-сервисов), опубликованных средствами автономного сервера, нужно либо в коде клиентов этих сервисов указывать явно логин и пароль, либо включить в вашу инфраструктуру реверс-прокси, при помощи которого добавить в заголовки запроса заголовок с параметрами авторизации.
Если клиентом вашего сервиса является какое-то внешнее приложение, реализованное не на 1С, проверьте, возможно оно поддерживает формат URL с явным указанием логина и пароля в виде http://login:password@host:port/endpoint.
Например, к сервису из моего примера выше от имени пользователя httpservice с паролем 12345 можно обратиться таким образом:
http://httpservice:12345@localhost:8314/hs/myservice/ping
Но такой способ поддерживается не везде, поэтому рекомендуется универсальный способ — использовать промежуточный реверс-прокси и добавлять с его помощью в заголовки запросов заголовок с данными авторизации.
Пробросить авторизацию при помощи реверс-прокси (nginx/Angie)
Этот способ подразумевает, что запросы от клиента вашего http-сервиса будут сначала попадать на специальный сервер (реверс-прокси), который уже будет перенаправлять запрос на http-сервис.
Одним из популярных реверс-прокси является сервер nginx или, в контексте импортозамещения, можно использовать, например, его отечественный форк Angie.
Для демонстрации возможности я создал следующий конфигурационный файл для Angie (он же подойдет и для nginx):
# angie-default.conf
server {
listen 80;
server_name _;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://host.docker.internal:8314;
proxy_set_header Authorization "Basic aHR0cHNlcnZpY2U6MTIzNDU=";
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
Здесь нужно обратить внимание на две строки, которые вам придется изменить, чтобы настроить данный файл под себя:
proxy_pass http://host.docker.internal:8314;
Команда proxy_pass говорит, что входящие запросы нужно перенаправить на хост/порт, указанные в качестве аргумента.
В моем случае я запустил автономный сервер на своей локальной машине на порту по умолчанию (8314), а Angie — в docker-контейнере на этой же машине. Имя host.docker.internal — это предопределенное имя хоста, по которому из докер-контейнера можно получить доступ к хостовой машине. Вам нужно будет заменить это на имя или IP-адрес вашего хоста, на котором запущен автономный сервер 1С:Предприятия.
Вторая строка, на которую нужно обратить внимание — добавление в запрос к нашему http-сервису заголовка basic-авторизации. Значение после слова Basic — это строка вида «логин:пароль», закодированная в base64:
proxy_set_header Authorization "Basic aHR0cHNlcnZpY2U6MTIzNDU=";
Средствами 1С закодировать строку можно следующим образом (в данном фрагменте кода логин и пароль из моего примера выше):
СтрокаАвторизации = "httpservice:12345";
ДД = ПолучитьДвоичныеДанныеИзСтроки(СтрокаАвторизации);
ЗакодированнаяСтрока = Base64Строка(ДД);
Сообщить(ЗакодированнаяСтрока);
// aHR0cHNlcnZpY2U6MTIzNDU=
Используя данный конфигурационный файл, я запустил докер-контейнер с Angie следующей командой:
docker run --name myangie -p 8080:80 -v "C:\Bases1C\angie-default.conf:/etc/angie/http.d/default.conf" -d docker.angie.software/angie
После этого мой тестовый http-сервис начал отвечать по адресу http://localhost:8080/hs/myservice/ping, не требуя авторизацию.
Заключение
С точки зрения публикации http-сервисов из расширений, установленных в информационной базе, автономный сервер не имеет никаких ограничений.
Так же, как и в случае с использованием веб-сервера (Apache/IIS), http-сервисы расширения, которые вы хотите опубликовать, нужно явным образом перечислить в конфигурационном файле. Только делается это не в файле default.vrd, а непосредственно в yaml-файле конфигурации автономного сервера.
Но указание параметров авторизации конфигурационный файл автономного сервера не поддерживает, поэтому в http-запросах к опубликованному при помощи автономного сервера http-сервису нужно явно указывать параметры авторизации.
Когда у вас нет никакой возможности повлиять на потребителя/клиента вашего http-сервиса, чтобы он явно указывал логин/пароль в запросах к вашему сервису, можно прибегнуть к «инфраструктурному» способу — использовать промежуточный реверс-прокси.
В качестве реверс-прокси можно использовать сервер nginx или его форк Angie, разработанного в России и сертифицированного на совместимость с РЕД ОС и Astra Linux SE.
Использование реверс-прокси вдвойне оправдано, потому что он также необходим для организации доступа к автономному серверу по защищенному протоколу HTTPS, т.к. сам автономный сервер работает только по HTTP.
