A
ну я имел ввиду, если отправлять в теле запроса токен, то он будет сторится пока открыта вкладка
нафига в теле слать токен, это просто сводит на нет всю твою запарку
Size: a a a
2019 November 15
W
В таком случае, надо ли реализовывать CSRF protection?
A
В таком случае, надо ли реализовывать CSRF protection?
я ответил выше
W
нафига в теле слать токен, это просто сводит на нет всю твою запарку
Ну я думал что надо в хедере отправлять токены, если это не объязательно, тогда не надо, можно про это забыть
JD
В таком случае, надо ли реализовывать CSRF protection?
Не все браузеры работают с samesite, посмотри на caniuse
A
Ну я думал что надо в хедере отправлять токены, если это не объязательно, тогда не надо, можно про это забыть
так в хедере и надо. Разница между хеадерами и телом тебе понятна?
W
так в хедере и надо. Разница между хеадерами и телом тебе понятна?
Да, понятна, но смотри, если я отправляю токен в куках с сервера, то какой смысл оптправлять ещё и в хедере?
W
Возможно я выгляжу топой, по-этому наперёд, извините
A
Да, понятна, но смотри, если я отправляю токен в куках с сервера, то какой смысл оптправлять ещё и в хедере?
аа как ты отправишь "куки" ?)
W
аа как ты отправишь "куки" ?)
Ааххаха, я понял к чему ты ведёшь)
A
#кратко_о_токенах
Сервер авторизации принимает логин и пароль, если все ок отвечает заголовками которые устанавливают защищеные куки. время жизни равное времени токена. Один токен для самого себя (его назаывают refreshToken) другой (или другие) для апи эндпоинтов - их называют accessToken. (время жизни меньше чем у первого токена).
Все это апи эндпоинты проверяют токен когда ты к ним ходишь. Если они видят что он заэкспайрился присылают тебе редирект заголовок на сервер авторизации который читает рефреш токен, обновляет ацеес токены (если скажем тебя еще не забанили или рефреш токен не истек) и редиректит назад на апи эндпоинт
Сервер авторизации принимает логин и пароль, если все ок отвечает заголовками которые устанавливают защищеные куки. время жизни равное времени токена. Один токен для самого себя (его назаывают refreshToken) другой (или другие) для апи эндпоинтов - их называют accessToken. (время жизни меньше чем у первого токена).
Все это апи эндпоинты проверяют токен когда ты к ним ходишь. Если они видят что он заэкспайрился присылают тебе редирект заголовок на сервер авторизации который читает рефреш токен, обновляет ацеес токены (если скажем тебя еще не забанили или рефреш токен не истек) и редиректит назад на апи эндпоинт
A
если access токен не истек то апи сервер просто отдает тебе инфу
W
Ну это я понимаю
W
Меня просто интересует нужно ли защищать от CSRF
A
ну говорят что еще нужен, но я не шарю как это работает
A
пусть кто-нибудь обяснит кто это делал
W
Ребята, стоит ли делать CSRF защиту и как это лучше реализовать?
A
вроде как если у тебя не стоит в заголовках что-то типо
Access-Control-Allow-Origin: *
то не нужно
Access-Control-Allow-Origin: *
то не нужно
