сессии на клиенте?
А чего Вы пытаетесь добиться? Зачем Вам ид хранить?
Сейчас у меня реализована JWT аутентификация. Проблема в том, что если один и тот же пользователь залогинится с одного браузера, а после с другого, то при логине на втором браузере изменится access и refresh токены, а следовательно на первом браузере по истечению времени жизни access токена пользователю нужно будет заново проходить логин, вызывая тем самым ту же ситуацию, но теперь для второго браузера. Посоветовали ассоциировать токены с сессиией. Т.е есть некая таблица в бд 1 User to Many Sessions, где для каждой сессии теперь пара своих токенов. Вот поэтапно разбираюсь с сессиями, и что-то не могу понять, как мне сохранить сессию так, чтобы если пользователь вошёл например с телефона, то пока RT для телефона не истечёт, он мог без всяких проблем зайти с этого телефона.
А где jwt токен на клиенте храните?
Это REST API пока что, клиента нет. Чисто постманом запросы кидаю)
А клиенты вообще будут с двух браузеров ходить? Вы до с# на чем писали, какой опыт? Почему спрашиваю В общем я тут почитал сообщения выше Вы ещё с синтаксисом не до конца разобрались, а уже пытаетесь работать с сессией, бд и куками) Вы уверены, что это нужно на этом этапе?)
Если у Вас браузер, кстати, и сессия есть, то может без jwt обычную аутентификацию через куки юзать? Тогда и проблемы не будет
Так дело в том, что я могу написать сам 2 клиента. Один например браузер. А второй мобильное приложение. И вот эта проблема очень сильно проявит себя. Про синтаксис там, это просто не обращал внимания о том, как работает инициализатор объектов. Как говорится пользовался, но не вникал)
Объясните мне, с чего это получение токена клиентом отменяет другие токены
Ну в мобильном приложении сессии не будет, например И как тогда быть, если к сессии привязаться?
Классически при логине создаётся рефреш токен на клиента и пишется куда нибудь в бд, и старый перестанет быть валидным
Если это jwt, откуда вообще взялась бд
А как по Вашему на сервере инфа хранится по токенам? Можно в памяти, если хотите суть та же
В токене и хранится
@m_slnk Этот вопрос ещё в силе)
Вот тут мне недостаточно знаний. По идее мне совсем не важно, есть ли поддержка сессий на самом клиенте. Запросы для получения данных к моему приложению моё приложение будет рассматривать как сессию по идее) А на клиенте кукис выставить с id этой сессии. Как тогда вообще делают приложения, где сервер - REST API, а клиенты и мобильное приложение под андроид, и под IOS и в сколько угодно браузерах можешь логиниться с разных IP и всё хорошо?
Насколько я понимаю, что так примерно в делают, только вместо ид сессии используется некий deviceId В браузере он может быть идентификатором сессии
Так всё-таки, допустим ограничим кейс двумя браузерами. Я пользователь, зашёл с хрома в своё приложение, полазил, закрыл. Прошли сутки. Я зашёл с хрома, Id сессии у меня поменялся? У меня стоит кука в хроме ещё? Или Id сессии у меня остался такой же?
В основном jwt, но если нужно на вебе защитить сессию, используют куки с httponly
сам проверил, получается, что когда в options.IdleTimeout я устанавливаю время, то по истечению этого срока на сервере для одного и того же клиента генерится новая сессия. Так что мне скорей всего надо как-то сделать так, чтобы сессия хранилась образно очень много и Idшник сессии хранился у меня в бд.
Или тогда уже не к сессии привязаться
Обсуждают сегодня