Техническая реализация запрета продажи маркированных товаров : Маркировка

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

Не охота ждать 25-го года, а охота сразу предусмотреть все возможные варианты и алгоритмы обновления токенов, и если токен ККТ нужно будет по аналогии с ТруАпи-шным получать (сначала пару uuid и data, затем, подписав data, - получать уже токен-колбасу, которая в десятки раз длиннее того токена, что сейчас в ЛК), то и хочу понять что сейчас происходит с этими токенами-колбасами, если их перезапрашивать в течение 10 часов, и следовательно - что возможно будет в таких же случаях происходить и с токенами для ККТ, которые действуют до 25 года, а после 25-го типа обещают сделать как а ТруАпи (насколько я понял).
Вот для чего я всё это "взбаламутил", лишь для того, чтобы учесть уже сейчас все возможные варианты, и не переделывать алгоритмы проверки свежести токенов и их обновления в случае нужды.
Можно конечно при каждом запросе запрашивать и получать свежий токен, но это лишнее время, и зачем это делать так часто, если токен не протух...
Вот как-то так.. )

Запросил с интервалом несколько минут, и в итоге получил - три токена-колбасы (согласно "Описанию True API" - так называемые "аутентификационные токены" или по другому - "ключи сессии" ).

У всех длина - 9877 символов, символы сначала все одинаковые, но в конце - пара сотен символов различается (в нескольких местах).

Так что - токены каждый раз возвращаются разные, это факт.

Чтобы понять валидные первые два или уже нет, а также сроки жизни - нужно что-то отправить в ЧЗ, пока не знаю что и как отправить, так что как будет возможность вернуться к этой задаче, и как только проверю - сообщу результаты.

поковырялся...
теперь подпись создаю не так (вручную), а автоматически, скриптами (почему раньше через js-скрипты не получалось - я так и не понял, видимо где-то "косячил", но теперь это и неважно)
;)

Я у себя вот так проверяю:


Функция ПопыткаАвторизоваться()
КодТекПольз = СтрЗаменить(ИмяПользователя(),".","");
ИмяфайлаТокена = КодТекПольз + "_tokenCRPT.txt";
сзЗаголовки = СоздатьОбъект("СписокЗначений");
сзЗаголовки.ДобавитьЗначение("utf-8", "Accept-Charset");
СтрОшибка = "";
СЗсохрТок = "";
Если ТипЗначенияСтр(ЗначениеИзФайла(КаталогИБ() + ИмяФайлаТокена, СЗсохрТок)) = "СписокЗначений" Тогда
ТекТокен = СЗсохрТок.Получить("токен");
КонецЕсли;
сзЗаголовки = СоздатьОбъект("СписокЗначений");
сзЗаголовки.ДобавитьЗначение("Ansi", "Accept-Charset");
сзЗаголовки.ДобавитьЗначение("application/json", "Content-Type");
ИНН = ВыделитьИНН(СокрЛП(глЗначениеПоУмолчанию("ОсновноеПодразделение").ИНН));
СтрОшибка = "";
Url = СокрЛП(Константа.АдресСервисаМОТП) + "/participants?inns=" + СокрЛП(ИНН);
Ответ = глXmlHttp_ВыполнитьЗапрос("GET", Url, "", ТекТокен, сзЗаголовки, СтрОшибка);
Если ПустоеЗначение(СокрЛП(Ответ)) = 1 Тогда
Возврат 0;
Иначе
Возврат 1;
КонецЕсли;
КонецФункции

Но, это не курл... Я с ним не очень дружу. На курл перепиши сам, ели хочешь...

похоже зря я заморачиваюсь с этим , - т.к. в свежих анонсируемых планируемых изменениях (Версия 267.0), читаю:
а алгоритм контроля и необходимости обновления токена с использованием expires_in я уже придумал и протестировал.

Так что терять лишнее время на это:
уже не вижу смысла, раз токены планируют сделать не в виде длинных токенов-колбас, а в виде uuid, и к тому же добавят в ответ на запрос ещё и срок жизни такого токена (по аналогии с токеном ККТ)

Самый главный и актуальный вопрос сейчас лично для меня, так это вот какой:
т.е. - единожды подписанные УКЭП данные в формате BASE64 (которые вставляются в параметр data при получении токена) - будут вечными или нет? (или их придётся каждый раз при обновлении токена - тоже заново подписывать, потому что пока непонятно, что подписывается - произвольные данные (как сейчас при получении токена ККТ), или что-то другое).

Вопрос важен потому, что если эти подписанные данные будут вечными, то не нужно иметь на каждом РМК УКЭП, достаточно подписать их единожды, и раздать на РМК, и тогда РМК будут обновлять протухшие токены без необходимости каждый раз что-то подписывать.

сейчас судя по всему это действительно так - мы на стенде до сих пор пользуемся подписанными данными для получения токена сформированными 10-12-2023 но что будет в 25-м никто не знает :) црпт еще те затейники

коллеги, а дайте пожалуйста несколько кодов маркировки (из групп: молочка, пиво, вода, сигареты) , которые точно есть в демонстрационном контуре
А то хочу потестить механизм проверки КМ через cdn-площадки.. - отправляю КМ, которые точно есть в продуктивном контуре, но в демонстрационном то они не числятся, я так понял..
Вот и прошу несколько КМ, которые есть именно в "песочнице"

у нас только касса :) никаких документов прихода и прочее мы не ведем
для тестов используем те марки что в МР - там в конце документа есть и на них есть зарезервированные ответы для реакции кассы :)

Наконец-то всё отладил, и с завтрашнего дня на всех РМК своих магазинов запускаю контроль КМ через api-запросы в ЦРПТ на предмет всех запрещённых статусов КМ.
Т.е. - если КМ не удовлетворяет условиям из Методических Рекомендаций (просрочка, уже продан, не в обороте, заблокирован ОГВ, ну и т.д..), то он в чек не встанет, с предупреждением огромными красными буквами - о причинах ;)

По каждому подобному случаю (при попытке пикнуть на РМК товар, который запрещён к продаже) - помимо того, что будет соответствующая запись в логах, так ещё при закрытии смены на РМК - будет автоматически отправляться по email письмо руководителю со списком выявленных за сутки подобных случаев (с указанием торговой точки, конкретного РМК, ФИО продавца, даты и времени попытки, самого КМ, ну и причины блокировки этого КМ)... Ну чтобы он (руководитель) - тоже был в курсе, что и где творится у его подопечных продавцов..

Осталось дождаться включения и опубликования url на продуктивном контуре CDN-площадок (которые работаю пока лишь на тестовом контуре).. Если ЦРПТ наконец-то "включит" механизм CDN-площадок на продуктиве, и кто-то первым про это узнает (надеюсь, что это будет коллега student) - просьба сообщить в эту тему, чтобы перевести механизм проверки с постоянного url (который отменят уже с 01.04.20024 согласно МР) - на алгоритм запросов через url-ы CDN-площадок.

Пока вот как-то так..
;)