KA
Да, в заголовках
Size: a a a
2020 August 18
РМ
меня к этому и научили 🙊🙈
И если у вас https и мы соглашаемся с Grigory в том, что украсть запрос намного сложнее, чем внедрить хакерский JS на страницу, то лучше использовать cookie http only
РГ
И если у вас https и мы соглашаемся с Grigory в том, что украсть запрос намного сложнее, чем внедрить хакерский JS на страницу, то лучше использовать cookie http only
да, у нас https
РМ
да, у нас https
ну тогда access не сохраняйте вообще, а refresh положите в http only куку
РМ
да, у нас https
получается к refresh у вас вообще нет доступа, она используется полуавтоматически
т.е. вы авторизуетесь,
/login
сервер возвращает access, который вы запихиваете в память (в Store или в http инстанс)
сервер устанавливает http only куку для refresh
/other-request уже будут с access_token в хедерах
далее вариант, что access_token истек
тогда
/other-request вернет 401 коде и вы делаете
далее нужно как-то получить новый токен при помощи нового запроса,
в этом запросе серверу будет доступен refresh и он выдаст новый токен
т.е. вы авторизуетесь,
/login
сервер возвращает access, который вы запихиваете в память (в Store или в http инстанс)
сервер устанавливает http only куку для refresh
/other-request уже будут с access_token в хедерах
далее вариант, что access_token истек
тогда
/other-request вернет 401 коде и вы делаете
далее нужно как-то получить новый токен при помощи нового запроса,
в этом запросе серверу будет доступен refresh и он выдаст новый токен
GS
получается к refresh у вас вообще нет доступа, она используется полуавтоматически
т.е. вы авторизуетесь,
/login
сервер возвращает access, который вы запихиваете в память (в Store или в http инстанс)
сервер устанавливает http only куку для refresh
/other-request уже будут с access_token в хедерах
далее вариант, что access_token истек
тогда
/other-request вернет 401 коде и вы делаете
далее нужно как-то получить новый токен при помощи нового запроса,
в этом запросе серверу будет доступен refresh и он выдаст новый токен
т.е. вы авторизуетесь,
/login
сервер возвращает access, который вы запихиваете в память (в Store или в http инстанс)
сервер устанавливает http only куку для refresh
/other-request уже будут с access_token в хедерах
далее вариант, что access_token истек
тогда
/other-request вернет 401 коде и вы делаете
далее нужно как-то получить новый токен при помощи нового запроса,
в этом запросе серверу будет доступен refresh и он выдаст новый токен
Можно добавить, что можно не дожидаться 401, а просто запросить заранее, ведь мы знаем, когда он истекает
РМ
Можно добавить, что можно не дожидаться 401, а просто запросить заранее, ведь мы знаем, когда он истекает
да
РМ
Мне далее не очень ясно
Вот пользователь закрыл браузер, открыл
у него есть только refresh и у него не graphql
делает запрос
/get-protected-content
что должен вернуть этот запрос?
контент + новый access?
тогда получается, что придется какой-то декоратор ко всем обработчикам запросов применять, чтобы «если запрос идет через refresh, то вернуть и контент и новый токен»
не очень ясно
Вот пользователь закрыл браузер, открыл
у него есть только refresh и у него не graphql
делает запрос
/get-protected-content
что должен вернуть этот запрос?
контент + новый access?
тогда получается, что придется какой-то декоратор ко всем обработчикам запросов применять, чтобы «если запрос идет через refresh, то вернуть и контент и новый токен»
не очень ясно
РМ
Можно добавить, что можно не дожидаться 401, а просто запросить заранее, ведь мы знаем, когда он истекает
вероятно все таки никак
насколько я понимаю последний блок текста посвящен этой проблеме
Can the user continue making authenticated API requests once the SSR page has loaded?
«Nope, not without some additional fiddling around unfortunately!»
насколько я понимаю последний блок текста посвящен этой проблеме
Can the user continue making authenticated API requests once the SSR page has loaded?
«Nope, not without some additional fiddling around unfortunately!»
РМ
да, у нас https
В общем) я думаю много инфы вам тут.
Refresh в cookie http only
Access в память
безопаснее по всей видимости, но есть некоторые траблики если резюмировать
Всем спасибо)
Refresh в cookie http only
Access в память
безопаснее по всей видимости, но есть некоторые траблики если резюмировать
Всем спасибо)
s
В общем) я думаю много инфы вам тут.
Refresh в cookie http only
Access в память
безопаснее по всей видимости, но есть некоторые траблики если резюмировать
Всем спасибо)
Refresh в cookie http only
Access в память
безопаснее по всей видимости, но есть некоторые траблики если резюмировать
Всем спасибо)
локал стор ничем не хуже куков.
оба варианта в теории не безопасны.
а на практике твои и мои сайты никому не нужны.
в плане атак.
так что юзай что тебе удобнее
оба варианта в теории не безопасны.
а на практике твои и мои сайты никому не нужны.
в плане атак.
так что юзай что тебе удобнее
РМ
локал стор ничем не хуже куков.
оба варианта в теории не безопасны.
а на практике твои и мои сайты никому не нужны.
в плане атак.
так что юзай что тебе удобнее
оба варианта в теории не безопасны.
а на практике твои и мои сайты никому не нужны.
в плане атак.
так что юзай что тебе удобнее
в LS вроде как можно достучаться из JS, а к http only кукам нет
D
с http only куками по сути работает только бэк
s
в LS вроде как можно достучаться из JS, а к http only кукам нет
и кто будет стучатся?
D
и кто будет стучатся?
любой xss с бэка
GS
Мне далее не очень ясно
Вот пользователь закрыл браузер, открыл
у него есть только refresh и у него не graphql
делает запрос
/get-protected-content
что должен вернуть этот запрос?
контент + новый access?
тогда получается, что придется какой-то декоратор ко всем обработчикам запросов применять, чтобы «если запрос идет через refresh, то вернуть и контент и новый токен»
не очень ясно
Вот пользователь закрыл браузер, открыл
у него есть только refresh и у него не graphql
делает запрос
/get-protected-content
что должен вернуть этот запрос?
контент + новый access?
тогда получается, что придется какой-то декоратор ко всем обработчикам запросов применять, чтобы «если запрос идет через refresh, то вернуть и контент и новый токен»
не очень ясно
Он делает запрос или открывает страницу?
Если открывает страницу, то SSR имея рефреш запрашивает аксесс, затем с аксессом получает контент и возвращает контент + новый рефреш
Если открывает страницу, то SSR имея рефреш запрашивает аксесс, затем с аксессом получает контент и возвращает контент + новый рефреш
РМ
и кто будет стучатся?
ну на случай если кто-то сможет внедрить js на страницу клиента
s
xss работает и с куками точно так же как и с локал стором
D
до httponly не достучится,не?