Веб-клиент 1С изнутри: браузер, веб-сервер и кластер

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

Выбор между клиентами простой. Тонкий клиент — для тех, кто работает в базе весь день. Веб-клиент — для удалённых сотрудников, планшетов, macOS без установленной платформы и разовых входов. Толстый клиент нужен только для обычных форм и Конфигуратора. Тема общая для платформы 8.3 и не зависит от конфигурации: БП, ЗУП и УТ публикуются одинаково.

Из чего состоит схема работы веб-клиента

В цепочке четыре звена. Если хотя бы одно не настроено, пользователь видит пустую страницу или ошибку подключения.

Что происходит при открытии документа:

1. Пользователь вводит адрес вида https://srv/buh/ru_RU/.
2. Веб-сервер по пути /buh находит публикацию и передаёт запрос модулю 1С.
3. Модуль читает файл default.vrd в каталоге публикации и узнаёт строку подключения к базе.
4. Браузер получает клиентскую часть платформы и метаданные форм.
5. Каждый серверный вызов (&НаСервере, запись, проведение, отчёт) уходит отдельным HTTP-запросом на веб-сервер, оттуда — в базу.

Файловый и клиент-серверный режим

В файловом режиме модуль расширения сам работает с файлом базы. Фактически серверная часть 1С выполняется внутри процесса веб-сервера. Поэтому учётной записи, под которой работает IIS или Apache, нужны права на чтение и запись в каталог базы.

В клиент-серверном режиме модуль ведёт себя как обычный клиент 1С. Он обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам. Серверный код выполняется в rphost, данные лежат в СУБД. Веб-сервер можно поставить на отдельную машину, в том числе в DMZ.

Публикация базы: модуль расширения и роль IIS или Apache

Сам по себе IIS или Apache не умеет говорить с 1С. Связь даёт модуль расширения веб-сервера, который ставится вместе с платформой. В установщике это компонент «Модули расширения веб-сервера» — его надо отметить явно, по умолчанию он не выбран.

Публикация из Конфигуратора

1. Запустите Конфигуратор от имени администратора Windows — иначе публикация не сможет записать файлы в каталог веб-сервера и в его конфигурацию.
2. Откройте Администрирование → Публикация на веб-сервере.
3. Укажите имя публикации (оно станет частью адреса), веб-сервер и каталог.
4. Отметьте, что публикуется: доступ для клиентских приложений, веб-сервисы, HTTP-сервисы, стандартный интерфейс OData.
5. Нажмите «Опубликовать» и перезапустите веб-сервер, если Конфигуратор предложит.

Публикация из командной строки

На сервере без графики или при массовой публикации удобнее утилита webinst из каталога bin платформы:

webinst -publish -apache24 -wsdir buh -dir "C:\inetpub\buh" ^
  -connstr "Srvr=srv1c;Ref=buh;" -confpath "C:\Apache24\conf\httpd.conf"

Для IIS вместо -apache24 и -confpath указывают ключ -iis. Удаление публикации — ключ -delete.

Что хранит default.vrd

Файл default.vrd — паспорт публикации. В нём строка подключения к базе (ib=), путь публикации (base=) и признаки того, какие сервисы включены. Минимальный пример для серверной базы:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
</point>

По адресу публикации платформа разносит разные виды доступа:

• 🖥 /e1cib/ — служебные запросы самого веб-клиента и тонкого клиента по HTTP;
• 🔗 /hs/ — HTTP-сервисы конфигурации;
• 📨 /ws/ — веб-сервисы SOAP;
• 📊 /odata/standard.odata/ — стандартный интерфейс OData.

Одна публикация обслуживает и браузер, и тонкий клиент. В тонком клиенте базу добавляют с типом расположения «На веб-сервере» и тем же адресом.

Веб-клиент, тонкий и толстый клиент: в чём разница

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

Практические следствия:

• 📁 Для выгрузки и загрузки файлов, работы с электронной подписью и некоторых внешних компонент в браузере ставят «Расширение для работы с файлами 1С:Предприятия». Платформа сама предлагает его установить при первом обращении.
• 🖨 Торговое оборудование и сканеры штрихкодов, подключённые через внешние компоненты, в браузере работают не все. Если компонента выпущена только под Windows-приложение, на кассовом месте нужен тонкий клиент.
• 🪟 Обычные формы и старые конфигурации на обычном приложении в веб-клиенте не открываются вовсе.
• 🧩 Модальные окна браузер не любит. Конфигурации на современных релизах написаны без модальности, а самописные доработки с Вопрос() вместо ПоказатьВопрос() в веб-клиенте выдают ошибку.

Лицензии

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

Скорость работы веб-клиента и как её поднять

Браузер выполняет интерфейс медленнее, чем родное приложение. Основные потери — на сетевых задержках: каждая кнопка, которая обращается к серверу, это отдельный HTTP-запрос.

Что влияет больше всего:

1. Пинг до веб-сервера. При задержке 100+ мс серверные вызовы складываются в ощутимые секунды на каждой форме. Веб-сервер ставят ближе к пользователям или к серверу 1С, в зависимости от того, где длиннее канал.
2. Число серверных вызовов в формах. Доработка, которая в цикле вызывает &НаСервере по каждой строке таблицы, в тонком клиенте почти незаметна, а в браузере тормозит. Решение — собрать данные одним вызовом, а для расчётов без формы использовать &НаСервереБезКонтекста.
3. Ресурсы веб-сервера. В файловом режиме серверный код крутится прямо в процессе IIS или Apache. Здесь важны память и процессор машины с веб-сервером.
4. Браузер. Свежие версии Chrome, Firefox, Edge, Яндекс Браузера и Safari работают быстрее старых. Десятки открытых вкладок с 1С отнимают память у каждой.

Что настроить на веб-сервере:

• 🗜 Включите сжатие ответов (gzip) — статические файлы веб-клиента и данные форм сжимаются хорошо.
• 🔁 Оставьте включённым keep-alive: повторное установление TLS-соединения на каждый запрос добавляет задержку.
• 📦 Не выключайте кеширование статических файлов в браузере. После обновления платформы веб-клиент сам загрузит новые файлы.

Безопасность публикации и права доступа

Публикация в интернет — это вход в базу для всех, кто знает адрес. Защита строится на трёх уровнях: канал, веб-сервер, сама 1С.

Канал

• 🔒 Работайте только по HTTPS. Сертификат ставится средствами IIS или Apache, 1С в этом не участвует. Бесплатный сертификат Let’s Encrypt подходит.
• 🚪 Не открывайте наружу порты кластера 1С (1540, 1541 и диапазон рабочих процессов). Наружу смотрит только 443 веб-сервера.

Веб-сервер

• Ограничьте доступ по IP-адресам или поставьте публикацию за VPN, если удалённых пользователей немного.
• Добавьте вторую ступень авторизации на уровне веб-сервера (базовая аутентификация или Windows-аутентификация в IIS), если база открыта в интернет без VPN.
• Учётной записи, под которой работает веб-сервер, давайте права только на каталог публикации и, в файловом режиме, на каталог базы.

Сама публикация

• ⚠️ Не прописывайте логин и пароль пользователя 1С в default.vrd и в адресе страницы. Такая публикация пускает в базу любого посетителя под этим пользователем.
• Публикуйте только то, что нужно. Если OData и веб-сервисы не используются, снимите их флажки при публикации.
• У каждого пользователя должен быть пароль. Включите требования к сложности и сроку действия паролей в настройках пользователей конфигурации.
• Права в базе работают как обычно: веб-клиент видит ровно то, что разрешают роли пользователя. Отдельных «веб-прав» нет.

Ошибки веб-клиента и как их устранить

Большая часть проблем возникает в двух ситуациях: при первой публикации и после обновления платформы.

Ещё три приёма, которые экономят время диагностики:

1. Откройте адрес публикации с самого веб-сервера (http://localhost/buh/ru_RU/). Если локально работает, а снаружи нет — смотрите брандмауэр, прокси и сертификат, а не 1С.
2. Подключите к той же публикации тонкий клиент с типом «На веб-сервере». Ошибка повторилась — проблема в публикации или базе, нет — в браузере.
3. Проверьте журнал ошибок веб-сервера: для Apache это logs\error.log, для IIS — журналы сайта и журнал событий Windows.

Частые вопросы