Гарри Поттер и подкапотное пространство веб-клиента

Основой этого доклада стало мое выступление на Infostart Event 2019 «Как работают управляемые формы и тонкий клиент 1С, взгляд из-под капота» – именно поэтому в названии темы опять упоминается «подкапотное пространство».

В выступлении 2019 года я рассказывал о своем опыте создания веб-клиентов в сравнении с работой веб-клиента и тонкого клиента 1С. Данный доклад будет больше похож на мастер-класс – мне хочется подытожить теорию и рассказать подробнее, как это все работает. С кусками кода, особенностями и так далее.

Принципы работы самописного веб-клиента

Самописный веб-клиент – это чаще всего подсистема для конфигурации 1С на платформе 8.3 и выше, потому что ему для работы требуется наличие HTTP-сервисов, которые появились в платформе 8.3.6. Еще лучше, чтобы конфигурация работала на платформе от 8.3.9.1919, потому что с этой версии произошли серьезные улучшения в работе платформы с с веб-сервисами и HTTP-сервисами: появилось переиспользование сеансов, улучшилась скорость работы HTTP-сервисов. Если запустить свой веб-интерфейс на версии 8.3.9.1919 и более старой версии – вы заметите разницу.

Запросы от браузера принимаются HTTP-сервисом и передаются на исполнение общим модулям 1С. В процессе выполнения запроса производятся необходимые действия с объектами ИБ 1С – мы можем вызвать некий произвольный HTTP-сервис, передать ему название функции, которую мы хотим выполнить, и при необходимости передать ей параметры. Например, если мы напишем HTTP-сервису «Клиент, выполни функцию ТекущаяДата() и верни результат», он нам вернет обратно текущую дату. Но если мы ему напишем «Очисти информационную базу», он очистит информационную базу, поэтому к вопросу безопасности мы обязательно вернемся.

После того, как HTTP-сервис выполнил свои действия, он преобразует результат в формат HTML и возвращает его браузеру пользователя, который отображает информацию на странице сайта.

Два варианта интеграции с сайтом

Наш веб-клиент может использоваться в двух режимах:

• интегрированный в сайт (чтобы запускать туда внешних пользователей);

• как автономное веб-приложение в интрасети (для доступа сотрудников компании).

В первом случае используется промежуточный сайт на PHP, во втором случае промежуточные скрипты располагаются в интрасети, чаще всего на том же компьютере, что и веб-сервер, где опубликован HTTP-сервис 1С.

При этом вам никто не запрещает работать с HTTP-сервисами 1С напрямую, обращаясь к нему из JavaScript и не используя промежуточный PHP-сервер. У этого подхода есть существенный минус, потому что выставлять базу данных для доступа извне не очень хорошо, но такие вопросы тоже легко решаются.

Архитектура в режиме интеграции с сайтом

Перед тем, как перейти к практике, необходимо рассказать, как работает вся эта система.

В стандартном варианте есть браузер пользователя, 1С-ка и промежуточный сайт между ними, который используется для доступа к HTTP-сервису 1С.

В первую очередь, промежуточный сайт необходим с точки зрения безопасности, чтобы не выставлять базу данных наружу. Мы создаем промежуточный сайт и доступ к HTTP-сервису 1С открываем только для IP-адреса, которому соответствует промежуточный сайт. Если кто-то со стороны попробует задолбить базу 1С запросами, у него ничего не получится. Конечно, можно и сам сайт задолбить запросами, но в этом случае база 1С не “ляжет”.

Пользователь открывает страницу на сайте, у него запускается промежуточный инициализирующий JavaScript, который перенаправляет запрос в 1С. Задача скрипта – получить запрос, модифицировать его, добавив IP пользователя и другие служебные данные, и перенаправить все это веб-серверу, на котором расположена 1С.

Веб-сервер выполняет авторизацию с помощью указанного в default.vrd логина и пароля. Также можно указывать логин и пароль пользователя 1С в PHP – сохранить их в неком скрипте на стороне промежуточного сайта.

У нас авторизация происходит через промежуточного пользователя 1С, через которого работают все посетители сайта, – его логин и пароль прописаны в default.vrd.

Когда пользователь авторизуется на сайте, он указывает не логин и пароль пользователя 1С, который указан в конфигураторе, а логин и пароль из отдельного справочника «Посетители сайта». Этот логин и пароль обрабатывается с помощью HTTP-сервиса.

Такой подход позволяет переопределять сеансы – если мы каждого пользователя будем запускать под своим логином и паролем в конфигураторе, то под каждого из них на сервере 1С будет создаваться сеанс HTTP-сервиса.

При этом пользователь может ничего при этом не делать, но сеанс уже создался, он занимает место в оперативной памяти. Чем больше будет таких сеансов открыто, тем больше будет занято оперативной памяти – если у нас зайдут 100 пользователей, они создадут 100 сеансов на сервере 1С. И, ничего не делая, они могут отнять большое количество оперативной памяти и прочих ресурсов сервера.

В нашем случае все пользователи сайта работают через одного пользователя, и за счет переиспользования сеансов 100 пользователей могут работать на одном сеансе сервера 1С – это существенная экономия ресурсов.

Пользователю присваивается идентификатор сеанса – он записывается в регистр сведений, где мы фиксируем информацию о том, что сессия появилась сегодня, в такое-то время, она активна и соответствует такому-то пользователю.

Идентификатор сохраняется в cookies браузера и позволяет в дальнейшем авторизоваться без ввода логина/пароля.

Время от времени мы регламентным заданием чистим неактивные устаревшие сессии.

После успешной авторизации HTTP-сервис передает управление процедуре общего модуля подсистемы, которая анализирует параметры HTTP-запроса и в зависимости от них выполняет некую процедуру.

Например, мы говорим коннектору: «Выполни функцию ТекущееВремя()», после чего HTTP-сервис через стандартный 1С-ный метод Выполнить() или Вычислить() просто запускает эту функцию (в данном случае, ТекущееВремя()) и получает результат.

В зависимости от статуса выполнения запроса этот результат формируется в виде HTML-кода.

И с помощью HTTP-сервиса этот код HTML-страницы возвращается обратно пользователю.

Далее все повторяется по циклу: выполняется HTTP-запрос, соответствующий следующему действию пользователя.

Архитектура в режиме веб-приложения в интрасети

В случае работы в режиме веб-приложения в интрасети исключается промежуточный сайт – есть браузер и есть некий компьютер в локальной сети, который является веб-сервером, там расположены все скрипты и 1С.

Скрипты запускаются из браузера прямо с этого сервера.

Разница в том, что авторизация выполняется в данном случае платформой 1С.

Дальнейшие действия аналогичны тому, что выполняется при работе через промежуточный сайт.

Схема работы веб-клиента. Плюсы и минусы выбранных подходов

На схеме показан процесс выполнения запроса из браузера пользователя к 1С при варианте интеграции через промежуточный сайт.

Работа собственного веб-клиента состоит в том, чтобы показать пользователю некую страницу инициализации – мы ее называем «Главной страницей». На главной странице может быть все, что угодно – например, список документов.

А далее, в зависимости от того, что хочет пользователь, выполняются определенные действия. Если пользователь кликнул на строку списка, необходимо выполнить запрос, который проанализирует, какой в строке находится документ, откроет его форму и покажет пользователю.

В нашем случае все запросы выполняются через один HTTP-сервис, ему можно в параметрах передать название функции, которую необходимо выполнить. У этого подхода есть свои плюсы и минусы.

Плюсы

• Ускоряется разработка кода. Если у вас появилась задача вызвать функцию, которую вы раньше не вызывали, вам не нужно дорабатывать HTTP-сервис, добавлять ему методы – вы вызываете функцию, указывая ее название на стороне клиента в JavaScript.

• Если вы не доработали код, нет необходимости переопубликовывать базу, все будет работать.

Из минусов:

• Можно выполнить любой код. При желании кто угодно может написать «Очистить информационную базу», и она действительно будет очищена. Чтобы этого не произошло, нужно проверять все входящие запросы.

При интеграции с сайтом используются промежуточные скрипты. Преимущества этого подхода:

• база у нас доступна только для IP сайта – кто угодно не достучится до HTTP-сервиса;

• вы защищены от DDOS средствами сайта.

Часто задают вопрос: что мы будем делать, если нас начнуть «ддосить»? Есть очень много инструментов, которые позволяют отловить DDOS для обычного сайта. Наши промежуточные PHP-скрипты – это и есть промежуточный сайт, для них действуют абсолютно те же правила, те же инструменты, как и для любого другого сайта. Поэтому отловить DDOS, определить его начало, легко и мы просто в определенный момент в нашем PHP-скрипте перестаем перенаправлять запросы в 1С. Наш веб-клиент при этом «ложится», но база 1С продолжает работать. На случай, если базу начинают долбить запросами, повиснет только промежуточная база – на работу основной базы это не повлияет. Но даже этот вопрос решается.

Из минусов:

• незначительно увеличивается время HTTP-запросов.

Состав и интерфейс решения

Давайте покажу, как это выглядит на стороне 1С.

На стороне 1С веб-клиент – это набор объектов, общих модулей, справочников. Это все встраивается в родительскую конфигурацию, которая должна стать CMS-системой, СУБД для веб-клиента.

В этой же подсистеме находится HTTP-сервис, который принимает все запросы и вызывает исполнение общих модулей основной конфигурации.

Встраивание происходит бесшовно – можно взять весь этот набор объектов и встроить его в родительскую конфигурацию как расширение или путем объединения с cf-файлом.

Потребуется немного доработать один-два общих модуля, но этого достаточно для того, чтобы веб-клиент заработал.

Вот так выглядит набор промежуточных скриптов для сайта – здесь js, css и php.

Эти скрипты у нас лежат на сайте под nginx – они кэшируются, из 1С не берутся. Я не говорю о том, что брать скрипты из 1С – плохо, у каждого решения свои плюсы и минусы, но у нас сделано так.

Промежуточный скрипт PHP выглядит вот так. Здесь ничего сложного нет, он небольшого размера – всего 230 строк кода.

Для перенаправления запросов используется любимый всеми curl.

Вот так выглядит js-скрипт, который отвечает за фронт. Здесь строк намного больше – 5722. Это все написано за более чем 10 лет. Эта версия уже пятая, первую версию мы начали писать в 2008 году. Мы ей даже сами не смогли пользоваться. Вторую было стыдно показать людям. Только третью можно было использовать так, чтобы было не стыдно.

Итак, у нас есть скрипты сайта и подсистема в 1С – что мы получаем на выходе?

На выходе мы получаем возможность быстро и красиво выставить наружу данные этой 1С-ки, причем с соблюдением всех норм безопасности.

На экране – один из примеров нашего интерфейса, который называется «Заказ товаров».

При входе в личный кабинет пользователь видит свой список заказов.

Он может создать новый заказ и подобрать в него товары, причем, ему будут выведены цены, которые установлены для этого конкретного пользователя.

На выходе мы получаем возможность дать доступ в 1С кому угодно: от сотрудника собственной компании в интрасети до внешнего клиента. Причем это будет выглядеть непохоже на 1С и будет работать даже на мобильных устройствах.

Авторизация пользователей

Я уже говорил про то, что промежуточные скрипты помогают нам задействовать переиспользование сеансов за счет того, что для авторизации мы используем свой собственный справочник «Посетители сайтов». В этом справочнике указывается:

• логин;

• пароль пользователя;

• его имя;

• и объект ИБ – ссылка на элемент какого-либо справочника, которому соответствует посетитель сайта.

Кому соответствует посетитель сайта, зависит от конкретной конфигурации, например:

• если речь идет о демонстрационной конфигурации «Заказы», то это будет контрагент (партнер);

• если речь о конфигурации «1С:ITIL», посетитель будет пользователем.

Мы используем свой алгоритм авторизации. Его плюсы:

• логин может быть привязан к справочнику любого типа – Пользователи, Контрагенты;

• за счет переиспользования сеансов нагрузка на сервер снижается в разы.

Минус:

• в ПараметрыСеанса.ТекущийПользователь всегда будет один пользователь – служебный, используемый для авторизации.

Минус не очень существенный, он ни на что не влияет, кроме RLS.

При поступлении HTTP-запроса в 1С вместе с его заголовками передается идентификатор сеанса, взятый из cookies. По этому идентификатору сеанса в регистре сведений мы находим посетителя сайта и подставляем его в документ.

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

Поэтому мы доработали свой скрипт init.php, добавили в инициализацию curl несколько строк:

• Первой строкой для параметра CURLOPT_HTTPAUTH указываем, что у нас используется basic-аутентификация.

• И второй строкой для параметра CURLOPT_USERPWD через двоеточие указываем имя и пароль пользователя.

Проблема уходит моментально. Вот два способа, чтобы запустить пользователя в 1С, не спрашивая у него логин и пароль.

В интрасети мы можем использовать стандартную авторизацию пользователей средствами 1С:

• Это не требует доработки кода для определения параметра сеанса ТекущийПользователь – существенный плюс.

• Но открытие отдельного сеанса на каждого пользователя значительно повысит нагрузку на сервер 1С – это существенный минус. От возможностей нашего сервера 1С зависит, сколько пользователей мы сможем запустить в базу данных.

Для внешних сайтов мы используем свой алгоритм авторизации через служебного пользователя. RLS в данном случае никак не работает, потому что все запросы будут выполняться под служебным пользователем – ограничения доступа к данным нужно эмулировать программно.

А для пользователей в интрасети, когда используется авторизация средствами 1С – RLS отработает нормально.

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

Здесь происходит вызов функции НайтиПосетителяСайтаПоИдентификаторуСеанса(ПараметрыЗапроса), который в переменную ПосетительСайта возвращает нам ссылку на элемент справочника «ПосетителиСайта».

Если сайт используется в интрасети, тогда:

ТекущийПользователь = ПараметрыСеанса.ТекущийПользователь;

В этом случае у нас RLS нормально отработает.

Но если у нас используется служебный пользователь, мы пользователя определяем как:

ТекущийПользователь = ПосетительСайта.ОбъектИБ;

В этом случае RLS будет всегда одинаковым независимо от того, кто зайдет. В данном случае ограничения доступа к данным нужно отрабатывать программно здесь, в коде.

Например, если зайдет руководитель подразделения, мы отобразим ему часть страницы, которая предназначена для руководителя, но часть страницы, соответствующая рядовому сотруднику, не будет показана. И наоборот.

Как в браузере выполнить функцию 1С

Как в браузере выполнить функцию 1С, получить результат и отобразить его на странице?

Точно так же, как вы делаете при попытке достучаться из одной 1С-ки к HTTP-сервису другой 1С-ки – у вас для этого есть объект «Новый HTTPЗапрос()».

В JavaScript тоже есть его аналог, называется XMLHttpRequest, он работает с теми же принципами, все то же самое – вам необходимо указать наименование хоста, к которому вы присоединяетесь, передать параметры, получить результаты и обработать параметры.

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

Давайте на примере разберем, как нам выполнить функцию, которая получает цену товара. Например – мы добавляем в табличную часть номенклатурную позицию, и она добавляется вместе с ценой.

Как это происходит? Сначала нужно показать 1С-ке, для какого товара мы хотим получить цену. Давайте запустим отладку веб-страницы и вызовем в отладчике метод

ГлобальныйКонтекст.Формы.ТЧ_Товары.ТекущиеДанные()

Отладчик веб-страницы выводит нам абсолютно то же самое, что и отладчик 1С, когда мы пытаемся получить ТекущиеДанные() для динамического списка.

У нас есть структура, которая содержит данные колонок этой строки. Здесь выводится цена, номенклатура, характеристика, количество и т.д.

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

Как в 1С есть структура, точно так же в JavaScript есть ассоциативные массивы, у которых есть связка «Ключ/Значение».

В данном случае, мы для определенной строки хотим получить цену по определенному виду цен.

Соответственно, мы в ассоциативный массив «Параметры» передаем JSON-структуру с данными всей строки.

Далее мы выполняем функцию НоменклатураПриИзменении() общего модуля ЗаказТоваров и передаем в нее сериализованное значение ассоциативного массива Параметры.

Функция «ВыполнитьФункцию1С» достаточно простая, у нее есть четыре параметра:

• ИмяФункции,

• Параметры,

• флаг «АсинхронныйВызов» – при асинхронном вызове мы функцию вызываем и интерфейс у нас освобождается, можно что-то параллельно делать. При синхронном вызове мы будем ждать до тех пор, пока 1С не выполнит запрос и не вернет данные.

Вот так выглядит функция «НоменклатураПриИзменении» в 1С – все данные из браузера передаются сюда в переменной «ПараметрыЗапроса» с типом Соответствие.

Через соответствие удобно получать параметры запроса в коде – например, получить вид цен через вызов ПараметрыЗапроса[“ВидЦен”]

Если параметр «ВидЦен» не будет передан в параметрах запроса, код не упадет, в значении ПараметрыЗапроса[“ВидЦен”] будет просто «Неопределено».

Обратите внимание, когда мы получили вид цен и данные текущей строки, мы получаем цену, помещаем ее структуру «ТекущиеДанные» и точно так же в виде структуры, конвертированной в JSON, возвращаем обратно в браузер.

И браузеры, и 1С работают в одинаковых терминах. Есть несколько уникальных типов данных, с которыми работает только 1С, но их немного. Поэтому разработать свой клиент 1С и работать с ним понятных 1С-нику терминах вполне реально.

Как передать ссылку из 1С в браузер и обратно

Я только что показал пример – чтобы получить цену номенклатуры, нам нужно передать ее (номенклатуру) в 1С.

У нас для этого есть две маленькие однострочные функции – ПредставлениеСсылкиДляСайта и ПредставлениеСсылкиОбъекта.

• «ПредставлениеСсылкиДляСайта» возвращает структуру, куда упакована ссылка и ее представление.

• ссылка упаковывается с помощью функции «ПредставлениеСсылкиОбъекта», где для нее сначала выполняется функция ЗначениеВСтрокуВнутр(), а потом КодироватьСтроку с параметром СпособКодированияСтроки.КодировкаURL..

Вот так мы получаем представление ссылочного объекта в 1С и передаем его в браузер, а потом из ссылочного представления получаем объект обратно.

Как видите, мы для этого используем функцию ЗначениеВСтрокуВнутр().

Конечно, сейчас правильнее использовать функцию XMLЗначение(), но для того, чтобы его использовать, нам необходимо помнить два параметра – ссылку и тип, к которому эта ссылка принадлежит.

А в случае использования функции ЗначениеВСтрокуВнутр() нам достаточно всего одного значения, выполняется функция довольно быстро, не тормозит. Если вдруг в каких-то будущих релизах платформы 1С эта функция перестанет работать, мы легко переделаем функцию ПредставлениеСсылкиОбъекта() – просто поменяем сериализацию на использование XMLЗначение(). Конечно, после этого в браузере представление ссылки будет выглядеть каким-то другим образом, но мы к этому тоже без проблем приспособимся.

Внизу на слайде показано, как сейчас в браузере выглядит представление ссылки.

Обратите внимание, здесь есть символы %22 и т.д. – это результат работы функции КодироватьСтроку(). Потому что результат функции ЗначениеВСтрокуВнутр() содержит фигурные скобки, а фигурные скобки по умолчанию в HTTP-запрос не пройдут – HTTP-запросы на таких служебных символах ломаются. Плюс JSON такое значение нормально не обработает, а мы любим JSON – в коде 1С мы все возвращаем через JSON, и в коде JS мы тоже сначала все данные кладем в ассоциативный массив, а затем при необходимости сериализуем в JSON.

Способ передачи данных между 1С и браузером – ассоциативный массив на стороне браузера и структура на стороне 1С. И наш любимый JSON.

Чтобы у вас все это нормально передалось, вам достаточно превратить ссылки в строку, чтобы не было служебных символов.

Любые другие строки, если вдруг в них будут знаки амперсанда, проценты, фигурные скобки и т.д., мы тоже обрабатываем функцией КодироватьСтроку(). А цифры и значения типа «Булево» передаются в JSON без изменений – этого достаточно, чтобы 1С и браузер могли обмениваться друг с другом информацией.

В итоге у вас на стороне клиента в конкретном поле input лежит ссылка на определенную номенклатуру – вы можете увидеть ее значение в атрибуте ref этого поля. А представление будет лежать в атрибуте value.

С точки зрения JS все сложнее – тут суть в том, что метод ГлобальныйКонтекст.Формы.ТЧ_Товары.ТекущиеДанные() возвращает массив со значениями полей текущей строки:

• Ссылки «Номенклатура», «ЕдиницаИзмерения» и «Характеристика» у нас превращаются в ассоциативные массивы с полями «Ссылка» и «Представление».

• «Количество» как было цифрой, так и осталось цифрой.

• А служебный реквизит «Использовать характеристики» – это false, ложь.

Но если вам нужен простой веб-клиент, и вам достаточно хранения данных в элементах, используйте это – все будет нормально работать.

Решение проблемы с кодировкой

Когда вы разрабатываете под веб, у вас есть две боли.

• Первая боль – гриды, таблицы.

• Вторая боль – кодировка.

Когда в 2016 году мы разрабатывали подсистемы отправки файлов для нашего веб-клиента, нормально отправить файл в 1С нам удалось с 99 попытки.

Кодировки – это боль. Просто 1С-ники об этом не знают, потому что 1С за нас хорошо поработала, у нас в принципе нет этой проблемы.

Но когда вы передаете данные из браузера в 1С, вы с этим намучаетесь.

Чтобы у вас было меньше проблем с кодировкой:

1. Кодировка вашего сайта должна быть только UTF-8. Если вам подсовывают другой сайт, у которого кодировка Windows-1251 и просят туда что-то интегрировать из 1С, всеми способами постарайтесь переделать в UTF-8. Вы потратите не один день, чтобы у вас в 1С приходили не кракозябры, а нормальная кириллица.

2. Чтобы из браузера информация приходила красиво, используется функция encodeURIComponent – она преобразует служебные символы в трехсимвольные конструкции вида %22 и т.д.

3. А в 1С вы просто эту закодированную строку пропускаете через функцию РаскодироватьСтроку. А если хотите передать это в браузер – используйте КодироватьСтроку.

4. Файлы передавайте в виде двоичных данных.

Запомните эти четыре основных принципа, они сэкономят вам часы и дни.

Безопасность

Перейдем к вопросу безопасности.

Изначально у нас был один HTTP-сервис, которому можно написать что угодно, например: «Покажи зарплату директора», и он показывал.

Но, конечно, мы понимали, что в будущем будем эту ситуацию исправлять. Несколько последних лет мы постоянно занимаемся тем, что делаем наш сервис более безопасным. Мы прошли тесты по OWASP и много других. Недавно мы запустили проект, на котором было одним из основных требований было – сделать так, чтобы выполнить произвольный код извне было невозможно.

Какие есть способы обезопасить информацию.

Первое – запретить доступ к базе 1С посторонним людям. Для этой цели мы используем PHP-скрипты на сайте – база 1С непосредственно из браузера недоступна, доступ к ней организован через промежуточные скрипты.

При этом на промежуточном сайте у нас нет данных пользователей – злоумышленник никакой информации не получит.

Зато если мы на промежуточных скриптах отловим этого нехорошего человека, мы заблокируем его DDOS и избежим атаки на базу данных 1С.

При этом систему безопасности локальной сети можно настроить так, чтобы запросы принимались только с IP промежуточного сайта.

Доступ к конфигурации 1С осуществляется через объект конфигурации HTTP-сервис через служебного пользователя.

Но даже если кто-то узнал реальный адрес базы данных, видит HTTP-сервисы и хочет зайти в базу через служебного пользователя, он не сможет нарушить работу вашей системы, при условии, что вы для своего служебного пользователя установите соответствующие права.

Права должны быть такими, чтобы пользователь мог только читать объекты, которые видит на сайте и писать объекты, которые нужно писать – ему даже просмотр не нужен. И самое главное – запретите для служебного пользователя запуск тонкого и веб-клиента.

В нашу конфигурацию, отвечающую за генерацию веб-форм, встроены дополнительные меры безопасности:

• Каждые 5 минут мы меняем идентификатор пользователя – пользователь не сможет перенести идентификатор на другую машину, чтобы зайти под другим пользователем, потому что пока он будет это делать, идентификатор «протухнет». Можно настроить так, чтобы делать это каждую минуту – проблем не возникнет.

• Мы не используем OData, используем HTTP-сервисы – поэтому когда запрос приходит, то он отрабатывается в функцией модуля HTTP-сервиса, где мы можем проверить легитимность запроса программно.

Например, если мы хотим отобразить форму личного кабинета, то мы сначала проверяем посетителя сайта – найден он или нет. Если он не залогинен – мы возвращаем текст формы «ИнициаторНеАвторизован».

Текст формы личного кабинета мы вернем только если пользователь авторизован – иначе мы ему вернем сообщение, что не знаем его.

Но да, это нужно будет делать практически в каждой функции.

Также у нас есть система, которая проверяет запросы на внедрение кода.

Результат HTTP-запроса формирует функция ExecuteСформироватьРезультат() – в ней много разных проверок.

Запрос будет выполнен только если функция НетВнедренияКода() вернет «Истина».

Функция НетВнедренияКода() разбирает имя функции, которую просят выполнить – по точкам, по скобкам и т. д. И далее, путем парсинга мы определяем, является ли эта функция достойной выполнения.

Функции, достойные выполнения, сохранены в настройках сайта.

Например, сейчас мы можем выполнить только функции, которые лежат в общих модулях ЛичныйКабинетИнициатораСайт и ЛичныйКабинетИнициатораСайтPython.

В этой табличной части мы можем как перечислить все функции поименно в формате ТестовыйМодуль.Тест(), так и указать имена общих модулей, все функции которых разрешены к исполнению.

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

Это один из способов – таким образом мы запрещаем к выполнению даже функцию «ТекущаяДата», нам ее ни в коем случае не покажут.

В последней версии мы добавили дополнительные справочники, в которых можно указать обработчики событий пообъектно, задать общие и глобальные правила доступа к объектам.

Например, если определенный справочник могут видеть и изменять все, нам нужно явно указать галочками, что для него допустимы и открытие, и запись – иначе он никак не будет показан в интерфейсе, даже если передать HTTP-сервису команду показать форму этого справочника. Или, если мы хотим, чтобы список документов «Заказ» выводился с фильтрацией по ответственному пользователю – это тоже нужно явно настроить.

Проблемы с безопасностью есть, они существенные, но они решаемы. Но помните, чтобы их решить, вам надо будет приложить серьезные усилия.

Формирование отчета с параметрами

Одна из самых распространенных задач – запустить в базу своих сотрудников, чтобы они могли получить расчетные листки за определенный период, или внешних поставщиков, которые могли бы увидеть остатки в своих взаиморасчетах.

Чтобы пользователь мог сформировать такой отчет, нужно немного:

• Дать пользователю возможность авторизоваться – я рассказал, как это делается.

• Обеспечить возможность выбора элементов ссылочных типов. Чтобы иметь возможность формировать отчеты, вам нужно решить, как вы будете выбирать ссылочные типы, чтобы потом эту ссылку передать запросом. Это основная проблема, потому что не так просто сделать так, чтобы при нажатии на кнопку выбора организаций появился список объектов. Нам для реализации этой функциональности пришлось потратить очень много времени. Если у вас небольшой набор элементов, самое простое – реализовать обычный выпадающий список,. Но если у вас 200-300 элементов или иерархия – выпадающий список не подойдет, здесь нужен обычный грид, а это вторая боль, про которую я говорил. В разработке веб-клиентов для 1С есть две проблемы: кодировки и гриды.

• Дать возможность ввести даты и время. Сколько бы нативным вам ни казался обычный элемент управления с типом date, он работает неправильно. Поэтому для ввода дат и чисел мы используем свои собственные обработчики.

Мы для ввода дат используем элемент управления типа text, к которому прикреплена библиотека xCal, отображающая календарь, и добавлены скрипты, которые обрабатывают нажатия клавиш, определяющие, какие символы мы можем сюда ввести. Только таким образом вы добьетесь нормального ввода дат и текста.

При формировании отчета вам нужно:

• Вызвать функцию 1С, передать в нее параметры отбора – я уже рассказал, как это делается.

• Проверить корректное заполнение параметров – это важно, потому что на сторону 1С можно передать все, что угодно

• Сформировать отчет с помощью СКД.

• Сохранить результат как табличный документ в формате HTML.

• Прочитать этот HTML-файл и вернуть браузеру его содержимое.

Если посмотреть, не так уж много действий. Сделать свой веб-клиент сможет любой 1С-ник среднего уровня.

Но с передачей результата отчета в браузер тоже достаточно много проблем

• Мы столкнулись с тем, что у диаграмм собственные стили – диаграммы в СКД очень красивые, выводятся в SVG-формате, но перед передачей результата стили у них нужно удалить.

• Почему-то диаграммы лежат на месте пустых таблиц-контейнеров – нам их нужно как-то на место этих таблиц-контейнеров переложить, доработать.

• Нам это вернется в виде HTML-документа с тегом body – получится один body внутри другого. Поэтому меняем корневой тег body на div.

• Дорабатываем стили таким образом, чтобы они не пересекались со стилями других отчетов. Если мы решили отобразить две таблицы на одной странице, стили будут пересекаться друг с другом, и вместо двух таблиц будет каша.

Вот функция, которая отвечает за адаптацию HTML-документа в нормальный HTML-код – как видите, чтобы сделать HTML-документ нормально читаемым, потребовалось 200 строк кода.

Если вы захотите встроить формирование отчета 1С в существующий сайт, где будет много других стилей, все эти преобразования нужны.

Но если вы делаете простой вариант – просто страничку, куда ваш сотрудник может залогиниться и указать период, за который он хочет получить отчет – вы можете использовать для выбора периода стандартные нативные поля с типом date и ничего не конвертировать. Просто возвращаете текст вашего документа, и в 99% случаях он будет нормально работать. Свой веб-клиент – это несложно.

Очень важное замечание – бывало, что мы формируем отчет, но он нам не показывает ничего, потому что мы его сформировали с помощью СКД.

Дело в том, что изначально мы нашему служебному пользователю дали права только на чтение объектов.

Казалось бы, если мы прочитали данные запросом, вывели результат в HTML-код и вернули пользователю – мы должны увидеть таблицу. Но с отчетом это не прокатит – чтобы СКД сформировала данные и дала их отобразить, вам нужны права на просмотр объекта, а не только на чтение.

Интерфейс веб-приложения

Если вы научитесь формировать отчеты, у вас, чаще всего, будут покрываться 80% запросов ваших заказчиков, которые хотят выставить 1С-ку наружу.

На слайде перечислены элементы страниц, которых достаточно для формирования интерфейса. Динамический список – это обычная таблица table в терминах html, в данном случае у нее фиксированная шапка.

Для формирования страниц у нас используется два варианта.

В первом случае мы берем HTML, разбиваем на шаблоны, храним их в 1С, на стороне 1С полностью все собираем, возвращаем в виде HTML-кода.

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

Во втором случае мы передаем на клиент только данные и при сборке страницы завязываемся на готовые фреймворки – такие как Vue, React, Angular.

В этом случае у нас появляются дополнительные места, которые могут сломаться. Поэтому сопровождение усложняется.

Поэтому второй вариант, когда мы собираем страницу уже на клиенте, для нас менее предпочтительный. Его минусы:

• больше действий при разворачивании веб-приложения,

• разработка занимает больше времени,

• сопровождение для обычного 1С-ника становится более сложным.

Поэтому в реальности у нас клиенты предпочитают первый вариант, так как это значительно упрощает процесс сопровождения продукта силами собственных специалистов 1С.

На слайде приведена статистика – использование второго варианта за последние пять лет понадобилось только один раз из тысячи. Это 1% от общего числа выполненных проектов. И только на одной таблице из 10.

Поэтому мы выбрали простоту сопровождения для наших заказчиков.

Тяжелые HTTP-запросы

Давайте обсудим вопрос – какого размера строку мы можем передать?

Дело в том, что 1С довольно интересно работает с запросами больших размеров. Большие размеры начинаются примерно с 1 МБ. 3 МБ – это много для нее, 10 – очень много.

Например, мы из интерфейса нашего хелп-деска хотим передать в 1С файл.

Нам нужно из браузера, в котором есть JavaScript, в котором есть объект, XMLHttpRequest (по сути, HTTP-запрос в терминах 1С), сказать – вот двоичные данные, ты прими их платформой, передай HTTP-сервису – он знает, что с ними делать. Преврати эти двоичные данные в файл и передай в 1С.

Когда файлы у нас были размером 53 килобайта, все было окей. Но когда файлы стали размером 10 МБ, они стали загружаться за 51 секунду. При этом:

• Сначала файл из браузера за секунду загружался на промежуточный сайт или напрямую в 1С. Отправляю файл, и счетчик загрузки за секунду доходит до 100%.

• Но HTTP-сервис в отладчике запускался только через 50 секунд.

Проблема в том, что когда мы в 1С через HTTP-запрос пытаемся передать большой файл, он принимается платформой, платформа за секунду его закачивает, возвращает ответ, что его приняла. Но потом она что-то 50 секунд с ним делает, и все это время в HTTP-сервис файл не доходит.

И мы никак не можем повлиять на то, что файл так долго где-то висит. У нас были проблемы с тем, что пользователь пытался прикрепить файл, ему сайт не выводил никакой реакции о том, что файл прикрепился – пользователь повторял процедуру несколько раз, а мы потом получали сразу 10 файлов.

Даже если мы работали через промежуточной сайт, который превращал файл в двоичные данные в ОЗУ – в HTTP-сервис он все равно попадал только через 50 секунд.

Оказалось, 1С плохо принимает большие файлы, но легко их сама скачивает.

В чем преимущество промежуточного сайта на сервере:

• Мы этот файл за 1 секунду закачиваем на промежуточный сайт и сохраняем как временный файл на диске.

• Дальше перенаправляем HTTP-запрос в 1C, но не включаем в него данные файла, а просто говорим HTTP-запросу, что пришел файл – он лежит на PHP-сервере с таким-то названием.

• 1С направляет HTTP-запрос на PHP-сервер, он забирает файл и загружает его за секунду.

В итоге вместо 51 секунды у нас получается 2,2 секунды.

Не знаю, почему так, возможно, есть более изящные решения.

Мы с этим столкнулись впервые в 2015 году, думали, что это проблема старых платформ, это исправится, но до сих пор не исправилось.

Вопросы

Какое у вас установлено время жизни сеанса и HTTP-соединения?

У нас используется стандартное время жизни сеанса – 20 секунд. Мы его никогда не меняли. В каких случаях есть смысл его менять? 1С долго запускается при первичном запуске. Если у нас кто-то зашел через HTTP-сервис и запустил 1С, в первый раз она загружается долго. При повторном запуске она будет загружаться быстро – это значит, что есть разогретый сеанс, который висит на сервере и через него все быстро выполняется. Есть смысл выставлять длительность жизни сеанса, чтобы хотя бы один сеанс висел разогретый и ждал, когда придет пользователь и захочет зайти в веб-интерфейс. Потому что на базах большого размера это заметно. Базы иногда могут подключаться по несколько секунд.

Как решается вопрос, если одновременно редактируется один и тот же документ?

Это, конечно же, необходимо блокировать на стороне сервера. Если честно, у нас пока такой необходимости не возникало. Если редактируется документ, он редактируется либо одним пользователем извне. Вопрос важный, для этого чаще всего нужно ставить программную блокировку. Либо сделать какой-то регистр сведений «Заблокированные объекты». Когда пользователь здесь открывает форму на просмотр, мы можем сразу создать соответствующую запись в регистре сведений и сказать, что этот документ менять нельзя.

Возможно ли заменить HTTP-сервис на SOAP веб-сервис? Если да, то какие различия в использовании будут при построении архитектуры?

Возможно, но зачем? HTTP-сервисы работают быстрее, они более оптимизированы для больших нагрузок. Если у вас нет HTTP-сервисов, потому что вы используете старую версию платформы – тогда да, возможно. Работать будет, но медленнее. У нас в промежуточном скрипте сейчас используется curl для HTTP-запросов, а здесь нужно будет поменять вызов curl на вызов веб-сервиса. И все будет работать.

В чем преимущество перед metadata.js – нагрузка на сервер ниже?

Про metadata.js ничего не скажу, это не наша разработка, у нас аналог. Но нагрузка на сервер у нас низкая – причем не в разы, а на порядки. В моем докладе 2017 года об этом подробно рассказано. Разница в экономии доходила до 50 раз – нам удавалось на одном сеансе веб-сервера запускать 50 пользователей.

А какой стандарт JSON используете? JSON-RPC?

Стандартный JSON, который отдает 1С или JS. Если нам нужно передать данные из браузера в 1С, я не собираю JSON руками. Я беру массив или ассоциативный массив и потом делаю JSON.stringify() и получают JSON. Аналогично и в 1С – я использую для этого ЧтениеJSON и ЗаписьJSON.

Получилось ли у вас реализовать постраничный вывод?

Да, он у нас не совсем постраничный. Это подгрузка строк. У нас есть справочник, в котором около 10 тысяч записей. Если бы мы их выводили сюда сразу все, то открытие этой формы заняло бы около 30 секунд. А сейчас у нас реализована порционная подгрузка – по сути, это тот же самый постраничный вывод, но здесь оно работает так же, как динамический список 1С. По умолчанию показываем 50 строк и потом подгружаем еще по 50. Обычный постраничный вывод тоже работает, но там есть особенности – для его отображения нужен индекс, по которому мы будем сортировать, получать эти порции. Пришлось помучиться. Но это реально, работать будет.

Доступно ли что-то из показанного вами в опенсорсе?

Мы этот вопрос существенно обсуждали с маркетологами и со специалистами разных областей. Они сказали, что не надо выкладывать, это сложный проект, сложный продукт. Если вы его выложите, у вас начнут просить дополнительную документацию по нему, вы погрязнете в объяснении, как это работает, а у людей сложится плохое мнение, потому что им не объяснили, как этим пользоваться. Поэтому у нас, к сожалению, есть возможность продавать за деньги и объяснять, как это работает только тем, кто заплатил за продукт.

Как выводится всплывающая форма?

Мы взяли здесь за основу Bootstrap. У нас не используется никаких глобальных библиотек, все свое, за исключением каких-то мелких компонент вроде xCal, который нам позволяет отображать календари. Мы взяли за основу окно Bootstrap, просто сделали для него собственный обработчик отображения. В данном случае, это div с классом modalwin. Только мы для него стиль display: block устанавливаем программно своим кодом. Плюс у него есть подложка. То есть реализовано совсем просто – это div с абсолютным положением на странице.

Как реализован ввод по строке – при каждом keyup происходит обращение к HTTP-сервису?

Не совсем при каждом, у нас реализовано отложенное выполнение функции, мы ждем 300 мс с момента окончания ввода текста – поэтому в итоге выполняется всего один запрос. Поищите в интернете информацию по ключевому слову debounce – вы найдете много статей на эту тему. В данном случае, у нас событие вызывается один раз при наступлении последнего нажатия.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Web-клиенты для 1С".