Мобильное приложение согласования на 1С: беспарольный вход по коду и офлайн-обмен

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

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

Авторизация без паролей: код из письма + токен доступа 1С

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

Шаг 1 — регистрация устройства. Приложение отправляет логин и хеш устройства. Сервер находит сотрудника, генерирует одноразовый 5-значный код и привязывает его к хешу устройства в регистре сведений:

Функция Регистрация(СтруктураДанных) Экспорт
    Пользователь = Справочники.Пользователи.НайтиПоРеквизиту("Логин", СтруктураДанных.login);
    Если Пользователь.Пустая() Тогда
        Возврат Ошибка("Не найден пользователь по логину.");
    КонецЕсли;

    ГСЧ = Новый ГенераторСлучайныхЧисел;
    Код = ГСЧ.СлучайноеЧисло(10000, 99999);

    МенеджерЗаписи = РегистрыСведений.Аутентификация.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.Пользователь   = Пользователь;
    МенеджерЗаписи.HashУстройства = СтруктураДанных.hash;
    МенеджерЗаписи.Код            = Код;
    МенеджерЗаписи.Записать();
КонецФункции

Отдельное регламентное задание разбирает очередь неотправленных кодов и рассылает их по SMTP — код приходит сотруднику на корпоративную почту. Так канал доставки кода отделён от канала запроса, а сам код живёт только до успешного входа.

Шаг 2 — проверка кода и выдача токена. При вводе кода сервер сверяет его с хешем устройства, считает попытки (после 5 неверных устройство блокируется) и, если всё верно, выдаёт токен доступа 1С (JWT, подпись HS256) — штатный механизм платформы 8.3.21+. Под каждого сотрудника автоматически создаётся пользователь информационной базы с единственным способом входа «Аутентификация токеном доступа», без пароля и без показа в списке выбора:

НовыйПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПользовательИБ.АутентификацияСтандартная    = Ложь;
НовыйПользовательИБ.АутентификацияТокеномДоступа = Истина;
НовыйПользовательИБ.ПоказыватьВСпискеВыбора      = Ложь;
НовыйПользовательИБ.Роли.Добавить(Метаданные.Роли.ИспользованиеСервисаОбменаСМобильнымПриложением);
НовыйПользовательИБ.Записать();

// сам токен подписывается ключом из константы
ТокенДоступа = Новый ТокенДоступа;
ТокенДоступа.Получатели.Добавить("mobile"); // имя HTTP-сервиса из default.vrd
ТокенДоступа.КлючСопоставленияПользователя = ИмяПользователяИБ;
ТокенДоступа.ВремяЖизни = 2592000; // 30 суток
ТокенДоступа.Подписать(АлгоритмПодписиТокенаДоступа.HS256, Константы.КлючПодписи.Получить());

Дальше все запросы приложение подписывает этим токеном, а веб-сервер (через default.vrd) сам проверяет подпись и сопоставляет запрос с нужным пользователем ИБ. Роль у такого пользователя ровно одна — доступ к сервису обмена, поэтому даже с валидным токеном из мобильного приложения нельзя «дотянуться» до остальной учётной базы. Подробный разбор самого механизма мы вынесли в статью JWT-авторизация в 1С.

Обмен, устойчивый к мобильной сети

Мобильное приложение работает автономно: сотрудник видит свои задачи и согласовывает их даже при плохой связи, а синхронизация идёт пакетами. В основе — штатные планы обмена 1С, «протуннелированные» через HTTP-сервис. Каждому устройству соответствует свой узел плана обмена (UUID узла = ID устройства), сервер отдаёт только изменения для конкретного узла.

Чтобы не гонять по мобильной сети лишний трафик и не упираться в ограничение HTTP-сервиса (нельзя вернуть «Хранилище значения» напрямую), пакет сериализуется через XDTO и сжимается перед отправкой:

Функция СформироватьПакетОтвета(Пакет) Экспорт
    // сериализуем в XML, затем сжимаем (уровень 9) и снова сериализуем как строку
    СжатыйПакет = Новый ХранилищеЗначения(Сериализовать(Пакет), Новый СжатиеДанных(9));
    Возврат Сериализовать(СжатыйПакет);
КонецФункции

Приём данных с устройства идёт через штатные «Чтение/Запись сообщения обмена» с явной обработкой конфликтов (приоритеты «Заменить в ЦБ», «Заменить в мобильном», «Обновление из ЦБ») и подтверждением номеров сообщений. Диспетчер сервисов разделён на понятные шаблоны — Registration, Synchronization, Update, Check, — а все ошибки клиента и сервера пишутся в отдельный регистр-журнал с автоочисткой. О том, как мы вообще проектируем backend для мобильных приложений 1С, — в статье Backend для мобильного приложения на 1С, а про выбор формата пакета — в XDTO vs JSON.

Гибкие карточки согласования

Согласование — это не просто «да/нет». Документ задачи несёт срок исполнения, срочность, контрагента, организацию, HTML-текст с телом заявки, вложенные файлы и — главное — настраиваемый набор действий и полей. В карточке задачи описываются свои команды (табличная часть «Команды задачи») и дополнительные поля с обязательностью заполнения и списками выбора, поэтому под новый тип согласования не нужно переписывать приложение — достаточно сконфигурировать документ на сервере:

• Команды задачи — динамические кнопки решения (например, «Согласовано», «Не согласовано», «Вернуть на доработку»), которые приложение рисует на форме.
• Дополнительные поля — комментарий, сумма, причина отказа и т.п., с флагом обязательности и предопределённым списком выбора.
• Исполнители — таблица сотрудников-согласантов; при входе устройства сервер сам регистрирует для него только его задачи.

Серверная сторона опубликована как HTTP-сервис на веб-сервере — как это делается на проде, мы описали в статье Публикация 1С на веб-сервере.

Что в итоге

Заказчик получил готовый продукт из двух частей — мобильное приложение и серверную конфигурацию, — спроектированный под масштаб до 5 000 устройств: беспарольный вход по коду из письма, изоляция мобильных пользователей от учётной базы через токены доступа и одну роль, автономная работа и экономный обмен по нестабильной сети, а также согласование любых типов документов без доработки под каждый новый маршрут.

Похожие мобильные решения на платформе 1С мы уже собирали в других отраслях — например, мобильное приложение торгового представителя (офлайн-сбор заказов) и приложение для приёмки в автосервисе.

Хотите такое же приложение под свою задачу — на мобильной платформе 1С, с безопасной авторизацией и обменом? Разбираем всю кухню на курсе Мобильный клиент 1С или беремся за разработку под ключ — оставьте заявку.