B
так а если не нужно кикать юзера при каждом закрытии
Size: a a a
2021 June 28
B
а только по времени
ОЛ
Есть паттерны по восстановлению опять же через куки)
B
киллер-фича во 👍
B
короче я понял что хейтеры куков идут куда-то подальше
B
в js есть событие закрытия страницы, можно же чистить куки и стор при этом событии зачем сессии и восстановления для авторизации
λ
Если говорить про схему с access/refresh, то первом лучше хранить в сешине или даже памяти, второе у куках httponly, secure да и ещё и для определеного path
B
Вот что я имел ввиду про куки и ssr, так вот проверяется, но скорее всего это не правильно потому что можно просто вписать auth куки вручную и тебе откроются страницы, а если там стор не подчищен то и контент
B
если кто--то хочет подсказать как сделать защищенный роутинг на ssr я буду благодарен
y
храню токен в localStorage и не парюсь пока, но вроде как это не очень безопасно
y
куки вроде как безопасней
el
не просто куки, а HTTP-Only куки
λ
secure забыл еще
CN
и флаг same-site: strict
AD
Выглядит убедительно. refreshToken тогда получается и не нужен в этой схеме? И на фронте никакие токены менеджить не нужно, только обрабатывать ошибки доступа, возвращаемые бэкендом?
CN
единственная проблема - фронт может думать что юзер залогинен, а бэк считать иначе (или наоборот). Но это легко фиксится фоновым разлогиниванием юзера при получении заголовка от бэка что юзер не авторизован
ИК
Вставлю и я очевидный коммент, только https иначе утечка все равно возможна, так как куки не будут зашифрованы
AD
Только оно не будет нормально работать с Webview, и для понимания, есть ли у пользователя рефреш токен, придется делать запрос на бэк