Как исправить ошибку 400 «В запросе отсутствует идентификатор авторизации (UUID)» при получении токена Честного Знака в 1С

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Торговля и дистрибуция
← На главную

При попытке интерактивной или регламентной авторизации в системе маркировки «Честный Знак» (ИС МП / True API) пользователи конфигураций 1С могут столкнуться с критической ошибкой: Код состояния HTTP: 400 с текстом «В запросе отсутствует идентификатор авторизации (UUID)» при выполнении метода api/v3/true-api/auth/simpleSignIn. Из-за этого прекращается обмен данными, невозможно проверить статусы кодов маркировки и выполнить отгрузку маркированного товара. Разберем причины возникновения этой проблемы и способы её устранения.

Причина ошибки и изменения на стороне Честного Знака

Проанализируем техническую сторону вопроса. Изначально механизм получения так называемого «Единого токена в формате UUID» работал по упрощенной одношаговой схеме: на подпись передавался ИНН организации, после чего отправлялся единственный запрос к методу auth/simpleSignIn, в ответ на который сервер возвращал 36-символьный токен.

ЦРПТ полностью отключил поддержку старой схемы без предварительного запроса пары ключей. Теперь получение единого токена формата UUID переведено на стандартную двухшаговую процедуру, аналогичную получению классического длинного JWT-токена:

  1. Вызов метода /auth/key, который возвращает пару значений: уникальный uuid (идентификатор текущей аутентификации) и случайную строку data.
  2. Преобразование полученной строки data в формат Base64 и её подписание усиленной квалифицированной электронной подписью (УКЭП) в формате CAdES-BES (присоединенная подпись).
  3. Повторный вызов метода /auth/simpleSignIn, в тело которого передаются: полученный ранее uuid, подписанные данные data, а также флаг "unitedToken": true и ИНН организации.

В типовых конфигурациях 1С при установленном признаке единого токена константа ИспользоватьТокенФорматаUUIDИСМП и модуль ИнтерфейсАвторизацииИСМПВызовСервера отправляли запрос по устаревшему одношаговому варианту. Поскольку сервер ЦРПТ перестал принимать запросы без параметра uuid, метод возвращает ошибку 400.

Способ 1. Быстрое восстановление работы: отключение токена формата UUID

Если требуется немедленно восстановить работу склада и отгрузок без изменения конфигурации и установки исправлений, переключимся на получение классического длинного JWT-токена. Разберем по шагам, как это сделать:

  1. Перейдем в раздел НСИ и администрирование (или Администрирование) → Интеграция с ИС МП (Обувь, одежда, табак...) → Настройки интеграции.
  2. Найдем флаг Использовать токен формата UUID и снимем его.
  3. Учтем важную системную особенность: значение этой настройки кэшируется платформой на уровне сеансов и модулей с повторным использованием возвращаемых значений. Чтобы изменение гарантированно применилось для регламентных заданий и рабочих мест, выполним перезапуск клиентских сеансов и службы сервера «1С:Предприятия» (либо перезапустим рабочие процессы кластера).
  4. Перейдем в форму актуализации токенов и выполним повторную авторизацию с помощью сертификата ЭП. Система перейдет на получение токена по стандартной схеме JWT, и авторизация пройдет успешно.

Способ 2. Установка официального патча БИСМП

Для сохранения возможности работы с новым коротким токеном формата UUID необходимо обновить программный код библиотеки интеграции (БИСМП). Фирма «1С» выпустила официальные патчи (исправления) для типовых конфигураций (ERP, КА, УТ, Розница, УНФ). Разберем порядок действий:

  1. Откроем раздел Администрирование → Обслуживание → Обновление программы → Установка обновлений и исправлений (патчей).
  2. Загрузим и установим актуальный патч для подсистемы интеграции с ИС МП, корректирующий модуль ИнтерфейсАвторизацииИСМПВызовСервера.
  3. После применения патча логика работы меняется: программа начинает сначала вызывать /auth/key, корректно считывать uuid и передавать его в теле /auth/simpleSignIn вместе с параметром unitedToken = true.

Особенности работы с подписью на сервере и МЧД

При настройке авторизации обратим внимание на важные технические нюансы криптографии:

  1. Подписание на стороне сервера: Если в базе настроено автоматическое регламентное обновление токенов, сертификат электронной подписи должен быть доступен серверу «1С:Предприятия». Если сервер работает под управлением Linux, требуется наличие криптопровайдера (например, CryptoPro CSP для Linux), а закрытый ключ сертификата должен быть установлен в хранилище системной учетной записи службы 1С (обычно usr1cv8). Если сертификат находится на физическом USB-токене на рабочем месте пользователя, автоматическое серверное обновление работать не сможет — обновление токена выполняется только вручную из клиентского сеанса.
  2. Использование МЧД (машиночитаемых доверенностей): При подписании запроса сертификатом физического лица в теле запроса обязательно должен передаваться параметр inn организации-доверителя, совпадающий с данными в системе маркировки.
  3. Формат подписи: Подпись должна быть сформирована в формате CAdES-BES в кодировке Base64 без разрывов строк и пробелов, иначе сервер True API вернет ошибку разбора данных.

Настройка розничных рабочих мест и исключение блокировок

Если ошибка авторизации токена ИС МП блокирует работу кассиров на розничных точках при проверке кодов маркировки, проанализируем параметры контроля:

  1. Проверим режим проверки в настройках интеграции: если установлен вариант проверки «При сканировании», программа пытается обращаться к True API при каждом считывании DataMatrix, требуя действующий токен ИС МП.
  2. Для касс ККМ переключим режим проверки кодов маркировки на проверку средствами ККТ (ФФД 1.2) в момент формирования и пробития чека.
  3. Убедимся, что на рабочих местах кассиров корректно настроена работа с локальным ТсПИоТ (разрешительный режим). Для работы разрешительного режима кассовому модулю требуется статический токен авторизации ТсПИоТ, что делает продажи в рознице независимыми от динамического сессионного токена True API.
← На главную