Универсальный скрипт для получения токена ККТ : Маркировка

Поменяй в "если задача уже выполняется, то применить правило:"
c
не запускать новый экземпляр
на
остановка текущего задания
(иначе на грабли можно наступить, я уже наступал)

Новая версия скрипта для получения токена по схеме "Единая аутентификация":

Изменения:

как выяснилось - если в параметрах скрипта при запуске указать отпечаток сертификата, который на аппаратном носителе (рутокен и т.д.), и этот аппаратный носитель забыли вставить в usb-порт (ну или usb-порт периодически "отваливается", как у одного из коллег ;) ) - то появляется окошко для выбора ключевого носителя, которое висит до тех пор, пока не вставишь носитель (или не передёрнешь его), либо пока не закроешь окошко вручную.

так вот если такая ситуация возникла при запуске скрипта через Планировщик - то скрипт не завершается, а "висит" бесконечно..

В данной версии - эта ситуация разрешена, и если скрипт не отработал задачу в течение 10 секунд (из-за предложения вставить носитель в usb) - то скрипт завершает свою работу по таймауту (а не висит а процессах до бесконечности).

Спасибо за внимание ;)
.

Вложения

unifiedauth.zip (4.16 Мб, 21 просмотров)

Доработал таймер, чтобы он "прибивал" криптопрошную утилиту лишь в том случае, если она запущена (а в предыдущей версии - таймер пытался "прибить" её в любом случае, даже если она отсутствовала в процессах)

на этом - думаю, что все ситуации уже учёл, какие могут возникнуть при работе скрипта
;)
.

Вложения

unifiedauth.zip (4.16 Мб, 29 просмотров)

Вы там это.... версионность что ли введите... А то потом будут вопросики...

версия внутри скрипта указана в первом комментарии (в формате ГГГГ.ММ.ДД.ЧЧММ), по дате публикации на форуме.
крайняя указана так:
(т.е. значит опубликована 22 сентября 2024 года)

Предлагаю очередной вариант скрипта для получения токена по схеме "Единая аутентификация":

В данной версии - в выходном файле json - кроме пары "token":"ключ_сессии" в конце добавлены ещё следующие пары:
"date":"Дата_получения_ключа"
"time":"Время_получения_ключа"

т.е. - теперь выходной json-файл содержит кроме самого токена (ключа сессии) ещё дату и время его получения (чтобы можно было знать - когда получен ключ, и рассчитать через какое время он "протухнет", зная, что срок жизни его - 10 часов)

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

Вложения

2024.09.27.1340_unifiedauth.zip (4.16 Мб, 47 просмотров)

Это все хорошо... Но, вт я что вспомнил:

И как будем "с этим жить" - ?
Нет, получили предположим, не проблема(или проблена, х.з., пока не пробовал), но вопрос не в этом - куда ее ставить?
В крупных фирмах - понятно, компов много, можно что-то придумать.
А в мелких? Один комп с учетной системой, один комп под кассу.
На том, где учетная система, обычно стоит еще и УТМ... А у него по техническим требованием недопустимо более одного токена аппаратного и одной КЭП ГОСТ.
А ЕГАИС с обезличенной - не работает. Только с директорской, или с физика с МЧД. Но, последний вариант - не работает для динамического токена в ЦРПТ...
Получается, надо два токена и две КЭП... Как это реализовывать физически?

PS Нет, я конечно понимаю что есть эмулятор и т.п., но, вопрос - как штатными средствами это сделать?

почему не работает?
если ЧЗ перейдёт на схему получения токена для ККТ по схеме "единая аутентификация" (что он и обещал), то - достаточно иметь в реестре копируемый сертификат сотрудника (у которого в ЧЗ есть МЧД), и никаких лишних рутокенов не нужно, и Рутокену для ЕГАИС мешать не будет.

Запускаем скрипт с нужными параметрами (отпечаток, контур, ИНН_ВыдавшийМЧД) и получаем ключ сессии

Сейчас же - так и работает.

Че-то я такого нигде не читал... Можно ссылку?
Пока, я так понял, что динамический ключ с 0103.2025(если не перенесут), будет получаться по "варианту 1", а не "единой авторизации"...
Только сейчас он возвращает всезда одно и то-же, и по сути он равен статическому из ЛК, то потом, с даты Х, начнет возвращать разные, видимо с привязкой ко времени получения.

в методических рекомендациях:
я так понимаю - что эта схема (единой аутентификации, как в TrueApi) - станет единой для всего - и для ККТ (для которых сейчас статический токен) и для документов (которые сейчас так и работают).
А схема с получением "X-API-KEY" - просто отомрёт.