знаю что с ним делать на фронте, то есть как проверять на фронте при каждой странице что токен валидный?
отправлять на бэк и там проверять
то есть создать один эндпоинт чисто для проверки токена? хорошо, а потом?
После проверки токена высылать информацию, ради которой требовалась авторизация. Можешь хоть не отправлять страничку без авторизации, а переводить на главную. Как минимум, я такую реализацию видел
предположим токен верный и я отправил true, как мне его использовать при фронте например если true то в нужную страницу, если фолс то в логин
тебе нужно в бд создать документ/объект сессии. там два поля: ссылка на юзера и токен (токен будет удаляться/обновляться в зависимости от его актуальности. когда получаешь токен от юзера, ищешь объект сессии с тем же токеном, получая таким образом ссылку на юзера
это ты про бек говоришь!
если у тебя по этому токену не найдётся объект сессии (то есть он не валидный), то ты просто говоришь пока юзеру
ты не совсем понял. Человек переходит на нужную страницу. Если токен подходит - человеку присылается информация со странички. Ну к примеру персональная страница. Если не подходит - человеку пишет "в доступе отказано". А там уже можешь с этим ответом делать что хочешь и либо автоматом перенаправлять, либо выводить на экран "авторизуйся для начала"
ты валидность на беке чекаешь, нет?
Проще говоря, к любому методу который требует авторизации - прикрепляй токен и проверяй
const user = найти в базе по токену ну вот if(!user) { редирект на страницу логина повторного }
А зачем тогда jwt если мы юзаем просто сгенеренный токен?
там иначе сессия работает? я просто один раз с ним что-то делал и не помню.. ещё где-то читал, что jwt вообще не стоит использовать
jwt можно проверять не обращаясь ни к какой бд. Там свой метод проверки
jwt это когда миллиард юзеров, а денег на auth инфраструктуру нет
Обсуждают сегодня