Здесь уже был подобный, но не было дано подробного ответа. И мой вопрос немного не о том.
Интересует вот что: при авторизации пользователя ему даётся токен, а где он потом сохраняется? В смысле при повторном заходе на сайт мне уже не требует авторизации, но при этом в куках ничего нет. И ещё зачем каждый раз отправляется запрос типа OPTIONS? Как я понимаю он нужен чтобы получить токен, но откуда он его получает, где хранится токен?
Я делаю API и хочу дать возможность внешним ресурсам (с других доменов) обращаться к нему. Но столкнулся с тем, а как после авторизации, получить токен? Заголовок Authorization появляется только после запроса типа OPTIONS, непонятно как и где хранится токен, как он определяется, ведь он всегда остаётся таким же, получается где-то в кеше хранится?
Очень буду благодарен, если мне кто-нибудь поможет. Документацию читал, но как я уже писал, неясно в итоге как получить токен уже авторизованного пользователя.
Интересует вот что: при авторизации пользователя ему даётся токен, а где он потом сохраняется?
на клиенте где-нибудь. Серверу об этом париться не стоит, он его не хранит. Ну то есть вам пришел JWT токен - значит надо проверить подпись. Подпись валидна - токен валиден.
В смысле при повторном заходе на сайт мне уже не требует авторизации, но при этом в куках ничего нет.
не авторизация а аутентификация. Ну и возможно токен передается в заголовках (обычно так во всяком случае).
И ещё зачем каждый раз отправляется запрос типа OPTIONS?
Это уже относится к CORS и называется freflight request. Перед каждым запросом ваш браузер спрашивает сервак "а что я могу по этому урлу делать?". Ну и сервер возвращает на основе вашего хоста и т.д.
Обычно options запросы не требуют аутентификации. Ну и как минимум в ишус трекере либы для jwt кто-нибудь 100% задавал вопросы о том как подружить либу и cors.
> Перед каждым запросом ваш браузер спрашивает сервак "а что я могу по этому урлу делать?". Ну и
> сервер возвращает на основе вашего хоста и т.д.
Сервер возвращает после OPTIONS "OK" в моем случае. Потом идёт обычный запрос на получение чего-нибудь и уже в этом запросе есть заголовок Authorization с токеном.
Мне в итоге так и остаётся неясным, как решить мою проблему: предоставить доступ к моему API внешнему миру? Это мне нужен запрос в API сделать, типа getMyToken, чтобы клиент мог получить токен и его передать при кроссдоменном запросе?
Судя по этой статье https://jwt.io/introduction/ не получится сделать так, как я хотел: т.е. есть клиентная часть сервиса и есть у него API. При авторизации на клиенте, я не могу использовать токен этой авторизации при кроссдоменных запросов? В случае использования API нужно каждый раз проходит аутентификацию? Либо можно сгенерировать долговременный (постоянный) токен для пользователя (многопользовательский сервис, где у каждого пользователя есть токен для API, так ведь делается, обычно? Но не ясно как такой токен генерировать и закреплять за пользователем или нечто подобное уже реализовано в Laravel?
сервер при успешном логине генерирует токен и отдает клиенту. Клиент его хранит у себя и отправляет с каждым запросом. Сервер проверяет подпись токена на каждый запрос.
jwt это не просто токен. Это просто зашифрованные данные. Дата старта + время жизни + данне + секрет. и это шифруют. На клиенте не нужно расшифровывать. Просто этот jwt можно передавать с сервера на сервер и получать данные. + это не нужна бд. Минус это придется юзеру руками каждый n часов логиниться
