IV
Других вариантов вроде и нету, ls или cookie
Size: a a a
2020 August 18
РГ
httpOnly cookie
cookie ж тоже не безопасно
РМ
Я отвечал на сообщение, где вы писали "вот предположим перехватили ваш запрос"
я понял, но не понял, что это меняет
перехват одного access_token намного менее страшно, чем перехват и access и refresh, поэтому не надо refresh закидывать в куки
перехват одного access_token намного менее страшно, чем перехват и access и refresh, поэтому не надо refresh закидывать в куки
IV
cookie ж тоже не безопасно
Абсолютно безопасности нету, тут исключается фактор доступа через js
GS
я понял, но не понял, что это меняет
перехват одного access_token намного менее страшно, чем перехват и access и refresh, поэтому не надо refresh закидывать в куки
перехват одного access_token намного менее страшно, чем перехват и access и refresh, поэтому не надо refresh закидывать в куки
Вероятность кражи токенов из запроса на порядки меньше кражи из js.
Если у вас можно красть данные из запроса, то можно и сразу пароль пользователя украсть
Если у вас можно красть данные из запроса, то можно и сразу пароль пользователя украсть
РМ
Вероятность кражи токенов из запроса на порядки меньше кражи из js.
Если у вас можно красть данные из запроса, то можно и сразу пароль пользователя украсть
Если у вас можно красть данные из запроса, то можно и сразу пароль пользователя украсть
1) а откуда такая вероятность?
2) где тогда хранить на клиенте токены?
2) где тогда хранить на клиенте токены?
GS
в local storage можно
в cookie наверно не нужно, чтобы каждый раз не передавать его
в cookie access, чтобы был доступ при SSR
в cookie наверно не нужно, чтобы каждый раз не передавать его
в cookie access, чтобы был доступ при SSR
> в cookie наверно не нужно, чтобы каждый раз не передавать его
У кук есть такой параметр, как path, который можно установить со значением AUTH эндпоинтов.
И тольно на них и будет слаться кука
У кук есть такой параметр, как path, который можно установить со значением AUTH эндпоинтов.
И тольно на них и будет слаться кука
GS
1) а откуда такая вероятность?
2) где тогда хранить на клиенте токены?
2) где тогда хранить на клиенте токены?
1. Мы работаем по HTTPS и считаем, что он "безопасный". Если считать, что он не безопасный, то у нас гора более серьёзных проблем.
2. Аксес в памяти, а рефреш в куке
2. Аксес в памяти, а рефреш в куке
AK
1) а откуда такая вероятность?
2) где тогда хранить на клиенте токены?
2) где тогда хранить на клиенте токены?
Если у вас используется https, то из вашего запроса невозможно украсть данные, тут вероятность стремится к нулю, а полный перебор невозможен.
IV
Важно что бы куки были httpOnly, а то обычные не сильно от ls отличаться будут
ПК
Если у вас используется https, то из вашего запроса невозможно украсть данные, тут вероятность стремится к нулю, а полный перебор невозможен.
Гугл - MITM
РМ
1. Мы работаем по HTTPS и считаем, что он "безопасный". Если считать, что он не безопасный, то у нас гора более серьёзных проблем.
2. Аксес в памяти, а рефреш в куке
2. Аксес в памяти, а рефреш в куке
а память у нас между клиентом и рендер сервером общая?
GS
а память у нас между клиентом и рендер сервером общая?
В общем случае - нет
РМ
В общем случае - нет
ну вот тогад как хранить, если есть SSR, то вариантов кроме кук нет и собственно с этого я начал свой ответ
GS
ну вот тогад как хранить, если есть SSR, то вариантов кроме кук нет и собственно с этого я начал свой ответ
А почему бы приложению не получить аксесс после инициализации на клиенте?
РГ
ну вот тогад как хранить, если есть SSR, то вариантов кроме кук нет и собственно с этого я начал свой ответ
у меня не SSR
РМ
А почему бы приложению не получить аксесс после инициализации на клиенте?
Тогда теряет смысл ssr
GS
Тогда теряет смысл ssr
Почему?
GS
Данные то уже срендерены и пришли
GS
данные юзера тоже можно в стор уже положить