NK
Стрим в течение 15-20 минут :) Извините за задержку
Size: a a a
2019 December 29
2019 December 30
RY
какие на сегодняшний день самые рабочие схемы для предоставления доступа к защищенным URL через авторизацию
1. Passport.js
2. Ручками класть куки, проверять с послед. запросами
в обоих случаях JWT
знаю эти. Может сейчас что-то новое придумали или можно и эти использовать?
1. Passport.js
2. Ручками класть куки, проверять с послед. запросами
в обоих случаях JWT
знаю эти. Может сейчас что-то новое придумали или можно и эти использовать?
DS
какие на сегодняшний день самые рабочие схемы для предоставления доступа к защищенным URL через авторизацию
1. Passport.js
2. Ручками класть куки, проверять с послед. запросами
в обоих случаях JWT
знаю эти. Может сейчас что-то новое придумали или можно и эти использовать?
1. Passport.js
2. Ручками класть куки, проверять с послед. запросами
в обоих случаях JWT
знаю эти. Может сейчас что-то новое придумали или можно и эти использовать?
Зачем переизобретать сесии?
RY
Зачем переизобретать сесии?
Passport и так на сессии основан, не?
DS
Passport и так на сессии основан, не?
Ну вопрос же был про что то еще
RY
Если я использую refresh и access tokens с JWT. Это те же самые сессии? мне же все равно их хранить где-то надо
IK
Если я использую refresh и access tokens с JWT. Это те же самые сессии? мне же все равно их хранить где-то надо
Access token с jwt не надо хранить
IK
Refresh tokenы если устраивает сценарии с logout all ( при логауте пользователь выходит отовсюду) тоже можно не хранить
IK
Хотя там лучше хранить
AV
Refresh tokenы если устраивает сценарии с logout all ( при логауте пользователь выходит отовсюду) тоже можно не хранить
Если не хранить Refresh token - как тогда сделать его одноразовым?
IK
В общем виде никак, поэтому и сказал что лучше хранить
RY
В общем виде никак, поэтому и сказал что лучше хранить
Вы в своем видео описали проблему, что JWT токен могут угнать, и разложили варианты сценарии, что в итоге все равно придется вернуться к "подходу" с сессиями. А разве sessionId так не уязвим и не страдает подобными проблемами? Не совсем понимаю где достоинства и недостатки одного над другим.
IK
JWT нужен только когда сервер выпускающий токен и сервер который будет потреблять API разные и хочется иметь возможность проверять валидность токена без доступа к серверу авторизации
RY
А если сервер один? Смысла нет?
IK
Нет
RY
Нет
То есть реализовывать Access/Refresh Token в случае с JWT глупо, так токен по своей сути одноразовый и дальше не нужен. А в случае с сессиями это как раз применимо? Спасибо
IK
Нет, не глупо. Плюс с сессиями нужна csrf защита если их на куках строить
D
@xanf_ua, в одном из своих последних "Ask me anything" ты советовал прочитать "Рефакторинг" Фаулера, на какую книгу после этой переводить своё внимание?)
IK