Size: a a a

NestJS — русскоязычное сообщество

2020 October 10

KL

Konstantin Lobkov in NestJS — русскоязычное сообщество
Только тут нужно проверку делать, чтобы бесконечно не редиректить
источник

KL

Konstantin Lobkov in NestJS — русскоязычное сообщество
Ангуляр разве не умер?
источник

KL

Konstantin Lobkov in NestJS — русскоязычное сообщество
:)
источник

AK

Alex Kulagin 🏡 in NestJS — русскоязычное сообщество
Лол
источник

А

Андрей in NestJS — русскоязычное сообщество
Из опыта, рефреши токенов больше всего бесит тех, кто пилит мобильные прилажки)))
Рассказал им схему как-то. И говорю «мол, access живет 2 часа, и вам придётся рефрешиться» в ответ услышал столько негодования и предложений сделать время жизни хотя бы несколько дней
источник

KL

Konstantin Lobkov in NestJS — русскоязычное сообщество
Кекв
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
А если токен увели. В СПА же ты не можешь токены в куках хранить.
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
Причем вместе с рефрешем.
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
Да и разлогинить на всех устройствах можно только через блэк-лист.
источник

MA

Maxim Afanasev in NestJS — русскоязычное сообщество
Anton Golovanov
А если токен увели. В СПА же ты не можешь токены в куках хранить.
Рефреш одноразовый, при входе реального пользователя с логином и паролем, рефреш злоумышленника станет не действительным. По крайней мере мы такую схему применяем. И Auth0 вроде тоже.
источник

А

Андрей in NestJS — русскоязычное сообщество
Anton Golovanov
А если токен увели. В СПА же ты не можешь токены в куках хранить.
Короче. У меня такая схема реализована.

Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
Maxim Afanasev
Рефреш одноразовый, при входе реального пользователя с логином и паролем, рефреш злоумышленника станет не действительным. По крайней мере мы такую схему применяем. И Auth0 вроде тоже.
Тогда пользователь может быть залогинен только на одно устройстве?
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
Андрей
Короче. У меня такая схема реализована.

Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
Токены в бд?
источник

MA

Maxim Afanasev in NestJS — русскоязычное сообщество
Андрей
Короче. У меня такая схема реализована.

Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
А как можно сделать невалидными все access токены для пользователя?
источник

А

Андрей in NestJS — русскоязычное сообщество
И рефреши тоже) короче юзеру придётся проходить процедуру авторизации)
источник

MA

Maxim Afanasev in NestJS — русскоязычное сообщество
Anton Golovanov
Тогда пользователь может быть залогинен только на одно устройстве?
У нас - да, но это бизнес-требование. А так - можно и несколько, тогда блокируется только украденный токен. Но схем много разных, зависит от требований.
источник

А

Андрей in NestJS — русскоязычное сообщество
Anton Golovanov
Токены в бд?
Нет. Но в бд хранится таймштамп. Который обновляется с случае, когда необходимо прекратить все сессии юзера.
источник

AG

Anton Golovanov in NestJS — русскоязычное сообщество
Ну, вот я нормальной схемы без хранения токенов в бд не нашел. А головная боль в том, что у нас все на микросеовисах на разных доменах. И авторизация - головная боль.
источник

А

Андрей in NestJS — русскоязычное сообщество
Но это чревато тем, что нужен запрос к бд, для проверки авторизации. Пока ок, а потом можно будет редис знать для этого
источник

MA

Maxim Afanasev in NestJS — русскоязычное сообщество
Мы храним рефреши в БД, а access - чисто stateless jwt.
источник