Использование нескольких токенов ЦРПТ одновременно: возможно ли это и как настроить стабильную работу?

← На главную

При автоматизации работы с системой маркировки «Честный ЗНАК» (ГИС МТ) разработчики часто сталкиваются с вопросом: как система ведет себя, если в одной организации работают несколько сотрудников, каждый со своей электронной подписью (УКЭП)? Возникает опасение, что получение нового токена авторизации для одного пользователя может «выбить» сессию другого. Разберем эту ситуацию подробно, проанализируем механизмы работы API ЦРПТ и выясним, как правильно реализовать программную логику в 1С.

Механизм привязки токена в ГИС МТ

Для начала проанализируем, как именно сервер ЦРПТ выдает права доступа. Токен авторизации (обычно это JWT-токен со сроком жизни 10 часов) не привязан к организации «в общем». Он выдается на конкретную связку: УКЭП (сертификат) + учетная запись пользователя.

Рассмотрим стандартную ситуацию: в организации есть два сотрудника, Иван и Мария. У каждого свой физический носитель с ЭЦП и своя учетная запись в личном кабинете ГИС МТ. Когда Иван авторизуется через API, система генерирует для него уникальный token_1. Когда через 5 минут Мария делает то же самое со своей подписью, система генерирует token_2. Эти токены существуют в системе параллельно и имеют независимые сроки жизни. Таким образом, работа нескольких сотрудников с разными ЭЦП абсолютно легитимна и поддерживается системой на архитектурном уровне.

Почему может возникать «отлуп» и долгие задержки?

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

Ограничение на количество сессий для одного логина. Если оба сотрудника пытаются авторизоваться, используя один и тот же email (логин) в системе, но разные подписи, ГИС МТ может ограничивать количество активных сессий. Рекомендуется создавать в ЛК отдельных пользователей для каждого сотрудника.
Превышение лимитов (Rate Limits). ЦРПТ жестко ограничивает количество запросов в секунду (RPS) с одного IP-адреса. Если несколько баз 1С или несколько потоков одновременно запрашивают токены и статусы кодов, сервер может временно заблокировать запросы, что выглядит как «долгое раздумье» и последующая ошибка соединения.
Динамический IP-адрес. В некоторых защищенных подсистемах токен может быть чувствителен к смене IP-сессии. Если на рабочем месте используется нестабильное интернет-соединение, токен может стать невалидным до истечения своего срока.

Особенности работы со Станцией управления заказами (СУЗ)

Если ваша задача связана не только с получением информации, но и с эмиссией (заказом) кодов маркировки, важно учитывать специфику СУЗ. В интерфейсе СУЗ предусмотрено разделение на «Устройства». Рассмотрим, как это использовать:

Для каждой отдельной информационной системы (например, основная 1С:ERP на складе и мобильное приложение для инвентаризации) можно создать свое «Устройство» в личном кабинете. Каждому такому устройству присваивается свой статический ClientToken. Это позволяет разграничить потоки заказов и избежать конфликтов при одновременной работе.

Реализация отказоустойчивой авторизации в 1С

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

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


Функция ПолучитьДействующийТокен(Сертификат, ПараметрыПодключения)
    
    ТокенИзБазы = ПолучитьСохраненныйТокен(Сертификат);
    
    // 1. Проверяем формальный срок годности
    Если ТокенИзБазы.ДатаИстечения > ТекущаяДата() Тогда
        
        // 2. Делаем тестовый запрос к профилю (проверка валидности)
        Ответ = ВыполнитьЗапросКГИСМТ("/api/v3/true-api/profile", "GET", ТокенИзБазы.Значение);
        
        Если Ответ.КодСостояния = 200 Тогда
            Возврат ТокенИзБазы.Значение;
        ИначеЕсли Ответ.КодСостояния = 401 Тогда
            // Токен "протух" раньше времени, нужно обновлять
            Лог.Добавить("Сессия недействительна, инициируем обновление...");
        КонецЕсли;
        
    КонецЕсли;
    
    // 3. Если дошли сюда, получаем новый токен
    НовыйТокен = АвторизоватьсяВЦРПТ(Сертификат, ПараметрыПодключения);
    СохранитьТокенВБазу(Сертификат, НовыйТокен);
    
    Возврат НовыйТокен;
    
КонецФункции

Практические советы по хранению токенов

Для обеспечения стабильной работы при использовании нескольких ЭЦП одновременно, придерживайтесь следующих правил:

Привязка к сертификату: Храните токены в регистре сведений, где ведущим измерением является отпечаток (thumbprint) сертификата. Это исключит ситуацию, когда один пользователь перезаписывает токен другого.
Использование прокси-сервиса: В крупных организациях целесообразно использовать единый прокси-сервер или промежуточный сервис для авторизации. Все запросы из разных копий 1С идут на этот сервис, который сам следит за актуальностью токенов и подписывает запросы одной «мастер-подписью», если это допустимо бизнес-процессом.
Обработка ошибки 429: Если сервер возвращает "Too Many Requests", реализуйте в 1С механизм Пауза (через ПодключитьОбработчикОжидания или циклы с проверкой времени) перед повторной попыткой получения токена.

Подведем итог: работа с несколькими токенами одновременно не только возможна, но и является штатным режимом работы ГИС МТ. Главное — правильно идентифицировать каждого пользователя и обеспечить корректную обработку ошибок авторизации (HTTP 401) в программном коде, не ограничиваясь простой проверкой времени жизни токена.

← На главную