При настройке интеграции 1С с внешними системами разработчики часто сталкиваются со странным поведением платформы «1С:Предприятие 8». Предположим, в нашей конфигурации создано несколько десятков Web- и HTTP-сервисов. В целях безопасности или оптимизации нам требуется опубликовать на веб-сервере только один конкретный сервис. Мы открываем Конфигуратор, переходим в меню администрирования публикации, снимаем флажки со всех ненужных объектов, оставляя активным лишь один, нажимаем кнопку «Опубликовать»... и обнаруживаем, что в созданном файле описания публикации все равно присутствуют абсолютно все сервисы конфигурации. Даже те HTTP-сервисы, которые мы вообще не планировали выставлять наружу.
Давайте подробно разберем по шагам, почему так происходит, как на самом деле платформа управляет видимостью сервисов, и как убедиться, что лишние интерфейсы действительно закрыты для внешнего мира.
Для начала проанализируем ситуацию и поймем, как Конфигуратор взаимодействует с веб-сервером (например, IIS или Apache). Результатом любой публикации является специальный XML-файл с расширением .vrd (обычно он называется default.vrd), который размещается в каталоге публикации на веб-сервере. Именно этот файл указывает веб-серверу, какие запросы нужно перенаправлять в информационную базу 1С.
Многие разработчики ошибочно полагают, что если снять флажок с Web-сервиса в окне публикации, то платформа физически удалит все упоминания о нем из файла default.vrd. Однако это не так. Платформа «1С:Предприятие» всегда выгружает полную структуру метаданных сервисов в XML-файл, но управляет возможностью обращения к ним с помощью специальных логических атрибутов. Таким образом, физическое наличие строк с именами сервисов в файле публикации вовсе не означает, что они доступны для внешних пользователей.
Давайте заглянем внутрь файла default.vrd и посмотрим на пример его содержимого. Структура публикации разделена на отдельные логические блоки для SOAP (Web) и REST (HTTP) сервисов.
Рассмотрим подробнее секцию Web-сервисов, которая объявляется тегом <ws>:
<ws pointEnableCommon="false">
<point name="MyTargetWebService" enable="true"/>
<point name="SecretWebService" enable="false"/>
<point name="OldService" enable="false"/>
</ws>
Проанализируем ключевые атрибуты этого блока:
pointEnableCommon — этот атрибут находится в корневом теге <ws>. Он отвечает за настройку «Публиковать Web-сервисы по умолчанию». Если мы устанавливаем его в значение false, это означает, что по умолчанию все веб-сервисы конфигурации ЗАПРЕЩЕНЫ к вызову, кроме тех, для которых явно указано иное.enable — данный атрибут прописывается для каждого конкретного элемента <point> (веб-сервиса).
enable="true".enable="false".Таким образом, хотя веб-сервис SecretWebService физически прописан в файле, обратиться к нему извне не удастся, так как его персональный флаг enable установлен в значение false на фоне отключенного общего доступа.
Теперь посмотрим на аналогичную ситуацию с HTTP-сервисами. За них отвечает тег <httpServices>:
<httpServices publishByDefault="false">
<service name="MyTargetHTTP" rootUrl="target" enable="true"/>
<service name="UnusedHTTP" rootUrl="unused" enable="false"/>
</httpServices>
Здесь логика абсолютно идентична:
publishByDefault="false" блокирует доступ ко всем HTTP-сервисам по умолчанию.<service>, где атрибут enable="false" надежно закрывает доступ к тем объектам, с которых мы сняли галочки в Конфигураторе.Чтобы окончательно развеять сомнения и убедиться, что отключенные сервисы действительно недоступны, выполним проверку вручную. Для этого нам не понадобится верить «на слово» содержимому файла default.vrd.
Для проверки Web-сервисов выполним запрос схемы WSDL. Откроем любой веб-браузер или утилиту для работы с API (например, Postman) и попробуем обратиться к схеме отключенного веб-сервиса по адресу:
http://<имя_сервера>/<имя_публикации>/ws/<имя_отключенного_сервиса>?wsdl
В ответ на этот запрос веб-сервер должен вернуть ошибку HTTP (обычно это HTTP 404 Not Found или ошибка авторизации/внутренняя ошибка сервера 500, так как платформа блокирует обработку данного адреса). В то же время обращение к разрешенному сервису (у которого enable="true") успешно вернет корректную XML-структуру описания WSDL.
Для проверки HTTP-сервисов попробуем отправить тестовый GET-запрос по их корневому URL:
http://<имя_сервера>/<имя_публикации>/hs/<корневой_url_отключенного_сервиса>/
Если сервис действительно отключен (стоит флаг enable="false"), веб-сервер вернет статус 404. Попытка вызвать разрешенный HTTP-сервис вернет адекватный ответ, предусмотренный логикой вашего кода в 1С.
Отдельно рассмотрим ситуацию, когда Web- или HTTP-сервисы добавлены в информационную базу с помощью расширений конфигурации. Здесь поведение платформы имеет важный нюанс:
default.vrd: publishExtensionsByDefault для HTTP-сервисов и аналогичным параметром для SOAP.Если вам требуется опубликовать строго один конкретный сервис из расширения, возможностей графического интерфейса Конфигуратора может не хватить. В этом случае нам придется отредактировать файл default.vrd вручную, аккуратно прописав имя сервиса и установив для него параметр enable="true", одновременно отключив автоматическую публикацию всех остальных расширений.
Иногда возникает ситуация: вы изменили настройки публикации в Конфигураторе, проверили файл default.vrd — там действительно все прописалось правильно (лишние сервисы получили признак enable="false"), однако внешние запросы к отключенным сервисам все еще продолжают работать. Почему так происходит?
Причиной является кэширование конфигурации самим веб-сервером или пулом приложений (особенно часто это происходит на IIS). Веб-сервер считывает настройки файла default.vrd при первом обращении и может кэшировать их в оперативной памяти.
Чтобы гарантированно применить изменения после перепубликации, выполним следующие действия:
iisreset
Или перезапустим конкретный пул приложений, обслуживающий нашу публикацию 1С, через диспетчер служб IIS.
services.msc) или с помощью команды в консоли Linux:
sudo systemctl restart apache2
Если перед вами стоит жесткая задача информационной безопасности, требующая, чтобы в файле default.vrd физически отсутствовали любые упоминания неиспользуемых сервисов (чтобы злоумышленник не мог даже узнать их имена при потенциальном доступе к файловой системе сервера), мы можем выполнить ручную очистку.
Разберем этот процесс по шагам:
default.vrd с помощью любого текстового редактора (например, Notepad++). Открывать файл необходимо с правами администратора.<point ... /> и <service ... />, которые относятся к неиспользуемым сервисам.enable="true".default.vrd и обязательно перезапустим веб-сервер, чтобы сбросить кэш.Важное примечание: помните, что при последующей перепубликации базы из Конфигуратора платформа 1С перезапишет файл default.vrd и снова вернет туда все имеющиеся в конфигурации сервисы. Поэтому ручную очистку имеет смысл производить на финальной стадии развертывания системы в продуктивной среде, ограничив в дальнейшем права на запись файла default.vrd для пользователя, от имени которого запускается Конфигуратор 1С.