V
И такой вопрос, что если не использовать refreshtoken, а сделать эндпоинт /refreshToken и передавать ему accesstoken который будет регенерить новый accesstoken ?
Size: a a a
2019 September 16
V
т.е., если запрос фейлится со статусом “expired”, или срабатывает таймер на обновление токена, то я просто отправляю запрос на /refreshToken передаю ему accessToken чтобы сгенерился новый accessToken
YS
Всем привет :)
Вопрос не в тему безопасности, а в разработчиские степи. Подскажите, кто что использует для дистрибуции тестовых версий приложений под Android (аналоги HockeyApp и AppCenter нужны).
Вопрос не в тему безопасности, а в разработчиские степи. Подскажите, кто что использует для дистрибуции тестовых версий приложений под Android (аналоги HockeyApp и AppCenter нужны).
V
Всем привет :)
Вопрос не в тему безопасности, а в разработчиские степи. Подскажите, кто что использует для дистрибуции тестовых версий приложений под Android (аналоги HockeyApp и AppCenter нужны).
Вопрос не в тему безопасности, а в разработчиские степи. Подскажите, кто что использует для дистрибуции тестовых версий приложений под Android (аналоги HockeyApp и AppCenter нужны).
Fabric
YS
т.е., если запрос фейлится со статусом “expired”, или срабатывает таймер на обновление токена, то я просто отправляю запрос на /refreshToken передаю ему accessToken чтобы сгенерился новый accessToken
А зачем делать аналог рефреш токена на отдельной ручке? Код там всё равно будет одинаковый, как и при использовании токена. Просто находится будет в другом месте (там где проходит аутентификация). То есть не очень понятен смысл переделывания схемы с токенами)
YS
Fabric
Спасибо!
c
А зачем делать аналог рефреш токена на отдельной ручке? Код там всё равно будет одинаковый, как и при использовании токена. Просто находится будет в другом месте (там где проходит аутентификация). То есть не очень понятен смысл переделывания схемы с токенами)
еще и менее безопасно
YS
еще и менее безопасно
Скорее больше возможностей выстрелить себе в ногу и не учесть чего-то. Например, сколько должен жить аксесс токен в таком случае (слишком долго нельзя, так как постоянная сессия по факту), слишком мало тоже не сделаешь, потому что какой он тогда access?)) Через сколько считать аксесс токен окончательно протухшим и не выдавать новый при обращении)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
c
Скорее больше возможностей выстрелить себе в ногу и не учесть чего-то. Например, сколько должен жить аксесс токен в таком случае (слишком долго нельзя, так как постоянная сессия по факту), слишком мало тоже не сделаешь, потому что какой он тогда access?)) Через сколько считать аксесс токен окончательно протухшим и не выдавать новый при обращении)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
ну как скорее, в первую очередь это разделение обязанностей, чтоб наложить на них разные требования
V
Скорее больше возможностей выстрелить себе в ногу и не учесть чего-то. Например, сколько должен жить аксесс токен в таком случае (слишком долго нельзя, так как постоянная сессия по факту), слишком мало тоже не сделаешь, потому что какой он тогда access?)) Через сколько считать аксесс токен окончательно протухшим и не выдавать новый при обращении)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
В общем я бы рекомендовал не изобретать велосипед на самом деле)
Например минут 10 будет жить аксесс токен и через 9 минут будем генерить новый
YS
А если я со своим токеном приду через час?
V
Просто не понятно зачем мне хранить рефреш токен, если он ничего не делает кроме как обновляет токен
V
А если я со своим токеном приду через час?
Экран login покажется
V
Единственный юзкейс который я смог придумать это быстрый логин с помощью пальца или пинкода
V
Достаем рефреш токен и запрашиваем новый аксесс
V
Но если в приложении не будет "быстрого" логина то и смысла рефреш токена я что то не вижу
V
Может я чего то не понимаю?
c
Может я чего то не понимаю?
Если у тебя злоумышленник перехватил AT, то он сможет бесконечно продлять сессию пользователя
c
В общем случае, если он перехватил AT, то у него будет 10 мин, чтобы что-то с ним сделать
V
Если у тебя злоумышленник перехватил AT, то он сможет бесконечно продлять сессию пользователя
Каким образом? Если к юзеру привязан 1 токен акссесс и старый токен который через минуту будет экспайред