AU
как правило, разделены части точками
Size: a a a
2020 February 24
VS
в jwt есть публичная часть, которую может клиент прочитать, а есть приватная, которая зашифрована на сервере
Смотря чем шифруешь
SS
в jwt есть публичная часть, которую может клиент прочитать, а есть приватная, которая зашифрована на сервере
аааа
SS
но вообще это плохая же практика проверять на клиенте срок jwt? Не лучше если сервер сам проверит и в случае чего отправить статус код , а на клиенте проверка, если статус код такой то - обновить токены
RG
S S
Здравствуйте, как можно на клиенте расшифровать jwt?
Он просто в base64 же - че там расшифровывать ты собрался?
SS
Он просто в base64 же - че там расшифровывать ты собрался?
проехали уже
AU
S S
но вообще это плохая же практика проверять на клиенте срок jwt? Не лучше если сервер сам проверит и в случае чего отправить статус код , а на клиенте проверка, если статус код такой то - обновить токены
это больше как раз и для клиента, что бы клиентское приложение могло вовремя понять, когда нужно обновить истекающий токен
AU
с 2 токенами механизм подразумевает, что даже если не делать обновление предварительное, то должен быть механизм повторного запроса. Например, в случае, если токен просрочен, сервер ответит, что просрочен, и нужно сделать запрос на обновление, а потом повторить предыдущий запрос, но уже с новым токеном. Но это всё должно для пользователя пройти без его участия(по возможности)
RG
это больше как раз и для клиента, что бы клиентское приложение могло вовремя понять, когда нужно обновить истекающий токен
Паблик часть и для сервера
RG
Паблик часть и для сервера
Просто клиент может класть болт на verify
AU
Просто клиент может класть болт на verify
да, всё верно)
AU
токен = паблик+прайват часть, если умелец решит поменять паблик часть(данные) и склеить новую паблик часть и старую прайват - на сервере токен не пройдёт валидацию, т.к. прайват часть высчитывается с участием паблик части
RG
S S
Перед каждым запросом клиент предварительно проверяет время жизни access token'а (да берем expires_in прямо из JWT в клиентском приложении) и если оно истекло использует refresh token чтобы обновить ОБА токена и продолжает использовать новый access token. Для большей уверенности можем обновлять токены на несколько секунд раньше.
Насколько я помню - expires это лонг - те такой подход факапится по таймзоне
+ секунда не секунда - может не быть связи / latency И так далее
Имхо резоннее натыкаться на ответ от сервера что токен сдох интерсептить его и слать рефреш + репит запроса. В таком подходе - в том что нет выделннного http кода на сдох токен
+ секунда не секунда - может не быть связи / latency И так далее
Имхо резоннее натыкаться на ответ от сервера что токен сдох интерсептить его и слать рефреш + репит запроса. В таком подходе - в том что нет выделннного http кода на сдох токен
AU
в теории получается 1 лишний запрос
AU
тот, который репит
СШ
почему запуская телеграм бота на джаве, самый простой, эхо текста.
В системе висит 20 штук разных PID с одной коммандой которая запустила бота
В системе висит 20 штук разных PID с одной коммандой которая запустила бота
СШ
это норм? )) я просто раньше в винде запускал всегда когда пилил проектики
B
🔫 maria reselle has been kicked — the only way to get this user back is for admins to manualy unban in chat settings.
Voters who chose to kick:
@nikita_by, @iWhiteN, @mind0wner, @alexsagent, @alcohate4u, @romank19, @Ainur_M, @rbkmn, @VitBlokhin, @SashaEgoro
Voters who chose to kick:
@nikita_by, @iWhiteN, @mind0wner, @alexsagent, @alcohate4u, @romank19, @Ainur_M, @rbkmn, @VitBlokhin, @SashaEgoro