Вопрос по JWT токенам:
Есть проект, два ключевых интерфейса в части авторизации - login и refresh, login взамен на имя/пароль отдает два токена - access и refresh, токены создаются абсолютно одинаково, разница лишь во времени жизни. По истечении времени access токена по классической схеме отправляется refresh и взамен присылается новый access.

1. В этой схеме можно взять refresh токен после истечения access и просто логиниться по нему, это нормально вообще?
2. В интернет статьях о JWT говорится что идея безопасности в том, чтобы можно было токен отозвать, если узнал что он украден, но в существующей у меня реализации я никак его не отзову, потому что он создается и никакой информации о нем не запоминается. (и по некоторым статьям это правильно, потому что jwt - stateless)
3. Я не понимаю вообще где безопасность в этой схеме, украв один из токенов можно какое-то время свободно получать доступ к сервису не вызывая подозрений.
Как сделать это православно, может кто вкратце описать или дать ссылку на хорошее описание?

Всем привет!
Вопрос на тему архитектуры интеграции - не могу разобраться как сделать правильно.
Задачи:
-Сделать витрину каких-то товаров, забирая данные у внешнего сервиса
-Вести учет изменения цен, остатков и пр. технических полей
Проблемы:
-Не понятно как мэнэджить измененные объекты и на какой стороне это лучше сделать (есть возможность попросить доработаться внешнюю систему). Выходит надо писать какой-то огромный код на то чтобы сравнивать отдельно каждое поле с тем что есть и т.д.
Ограничения:
-Инициатором запроса может быть только наша система, принимать мы ничего не можем.
-Очередей нет
-Код должен быть синхронным

Спасибо!
Если бы ты смог конкретизировать в какую сторону смотреть, был бы очень признателен )

такие системы называются ETL, для них есть как готовые паттерны те что я скинул выше так и готовые либы, например apache camel, spring integration итп, есть даже книжки. смысл в том чтобы представить интеграционное решение в виде цепочки обработчиков которые умеют делать маленькие части работы и месседжей с необходимой информацией для каждого обработчика, пробуй плясать от этого

Всем привет, вопрос по крон выражениям. cron = "0 17 12 * * *" это значит ежедневно в 12:17?

Ну это не чатик по крону, а ответ на такой вопрос есть в мануале, камон

Всем привет, вопрос по крон выражениям. cron = "0 17 12 * * *" это значит ежедневно в 12:17?

Погугли, есть в интернете миллион интерпретаторов которые расшифруют твой крон

Всем привет, вопрос по крон выражениям. cron = "0 17 12 * * *" это значит ежедневно в 12:17?

1. акцесс и рефреш токен отличаются скопом. По рефреш токену нельзя ничего сделать, кроме получения акцесс токена.
2. поверх jwt нужно самому реализовывать механизмы отзыва, используя какой-либо сторедж

что значит "скопом"? я же говорю, вот в текущем виде я отправляю refresh токен вместо access, когда access уже истек и у меня всё работает.
т.е. если у меня условно access действует 1 час, а refresh 2 дня, то украв refresh злоумышленник может 2 дня ходить на сервис. Мне искусственно нужно в refresh токен писать какой-то отличительный признак, чтобы если в запросе пришёл в поле access: <refreshToken> то сервер его считал невалидным, так это делается обычно?

что значит "скопом"? я же говорю, вот в текущем виде я отправляю refresh токен вместо access, когда access уже истек и у меня всё работает.
т.е. если у меня условно access действует 1 час, а refresh 2 дня, то украв refresh злоумышленник может 2 дня ходить на сервис. Мне искусственно нужно в refresh токен писать какой-то отличительный признак, чтобы если в запросе пришёл в поле access: <refreshToken> то сервер его считал невалидным, так это делается обычно?

Всем привет, вопрос по крон выражениям. cron = "0 17 12 * * *" это значит ежедневно в 12:17?

значит вы сделали не так,как нужно. Рефреш токен по определению служит лишь для того, что бы обновлять access, он не может использоваться для доступа к сервису. судя по ``что значит "скопом"?`` вообще мало понимаете, как это должно работать.