RS
Size: a a a
2019 October 03
RS
что-то странное ты говоришь, но все равно хорошо, что ты разобрался с JWT
RS
осталось хорошо разобраться с сессиями)
ŹR
Скорее всего вы НЕ разобрались с jwt и у вас все дырявое
YS
лучший аргумент - не разобрался. иди разбирайся. кука подписыватся каким-то ключом. значит ее все равно нужно как-то идентифицировать. значит все равно - лишняя работа
именно так, надо разобраться в обоих
ŹR
Потому что, как уеж было сказано - для реализации НЕ дырявых jwt надо подзаебаться
D
осталось хорошо разобраться с сессиями)
осталась понять зачем это нужно) товарищ скинул статью - jwt зло. я почитал статью, аргументов не увидел. мб ты мне скажешь чем jwt плохо?
ŹR
С реализацией рефрешей, блеклистов, изменения солей - и т.д.
YS
осталась понять зачем это нужно) товарищ скинул статью - jwt зло. я почитал статью, аргументов не увидел. мб ты мне скажешь чем jwt плохо?
ну для начала, потому что куки - это основа веб, и хотябы знать механизм работы нужно
ŹR
чеклист:
На сколько вы защищены от XSS?
Что делать, если токен требует инвалидации?
Где он хранится на клиенте, и кто имеет к нему доступ?
Что, если с этим токеном ДРУГОЙ человек придет в ваше АПИ?
На сколько вы защищены от XSS?
Что делать, если токен требует инвалидации?
Где он хранится на клиенте, и кто имеет к нему доступ?
Что, если с этим токеном ДРУГОЙ человек придет в ваше АПИ?
YS
+ лишний запрос
YS
постоянно
YS
а самое главное
YS
и смешное
ŹR
На рефреш - лишний запрос
YS
проблема:
YS
Авторизация пользователей
YS
есть решение
YS
готовое
D
чеклист:
На сколько вы защищены от XSS?
Что делать, если токен требует инвалидации?
Где он хранится на клиенте, и кто имеет к нему доступ?
Что, если с этим токеном ДРУГОЙ человек придет в ваше АПИ?
На сколько вы защищены от XSS?
Что делать, если токен требует инвалидации?
Где он хранится на клиенте, и кто имеет к нему доступ?
Что, если с этим токеном ДРУГОЙ человек придет в ваше АПИ?
а куку нельзя украсть?