IG
Но если еще мобила, то да, нужно специально продлять токен
Size: a a a
2019 October 01
AR
да что угодно. что и зачем появляется?
AR
если на мобиле то что и зачем?
AR
(ну и нас тут веб, для просто ты уж)
AC
да что угодно. что и зачем появляется?
Смысл в том чтобы не слать каждый раз user/password в запросе. Типа ты залогинился, получил какой-то токен и какое-то время сервер верит этому токену
A
Просто перед посылкой проверяем в каком состоянии токен сейчас - если его нет - говорим что надо залогиниться и не шлем ничего. Если рефреш в процессе - ретрай через ну не знаю 2 секунды, если токен стух - послать рефреш
Но тогда получается при каждом запросе к серверу, добавляется ещё проверка токена. т.е. х2 запросов.
AC
Но, токен можно ведь и спиздить, поэтому его надо обновлять периодически, чтобы спижженый протух
AR
Смысл в том чтобы не слать каждый раз user/password в запросе. Типа ты залогинился, получил какой-то токен и какое-то время сервер верит этому токену
а кто и зачем шлет user/password в каждом запросе?
AC
а кто и зачем шлет user/password в каждом запросе?
Ну а как ты пользователя идентифицируешь?
IG
> т.е. х2 запросов.
ну это как на сервере реализовано
ну это как на сервере реализовано
AC
Но тогда получается при каждом запросе к серверу, добавляется ещё проверка токена. т.е. х2 запросов.
Нет. Ты шлешь запрос с имеющимся токеном, а сервер его либо принимает, либо репортит обратно что он протух
IG
Токен может быть подписанными данными, из которого ты достанешь словарь с пользователем, только нужно проверить сигнатуру
IG
тогда лазить в базу не нужно
IG
А если нода одна, то в памяти хранить
AC
> т.е. х2 запросов.
ну это как на сервере реализовано
ну это как на сервере реализовано
Там про другое вопрос, Вань. Имеется в виду что надо перед каждым запросом делать отдельный запрос с проверкой токена (нет)
AR
Ну а как ты пользователя идентифицируешь?
авторизацию в вебе испокон веков принятно делать так:
1. чувак авторизовывается
2. ему заводится сессия
2.1. сессия хранится на сервере, на клиенте только session-id, секретность этого айди в этом случае и является залогом секьюрити
2.2. сессия подписывается сервером и кладется в куку / локал стораж / жс-переменную клиенту. при каждом запросе проверяется валидность подписи
1. чувак авторизовывается
2. ему заводится сессия
2.1. сессия хранится на сервере, на клиенте только session-id, секретность этого айди в этом случае и является залогом секьюрити
2.2. сессия подписывается сервером и кладется в куку / локал стораж / жс-переменную клиенту. при каждом запросе проверяется валидность подписи
AR
зачем и для чего вы тут токены протухающие начали изобретать?
AC
авторизацию в вебе испокон веков принятно делать так:
1. чувак авторизовывается
2. ему заводится сессия
2.1. сессия хранится на сервере, на клиенте только session-id, секретность этого айди в этом случае и является залогом секьюрити
2.2. сессия подписывается сервером и кладется в куку / локал стораж / жс-переменную клиенту. при каждом запросе проверяется валидность подписи
1. чувак авторизовывается
2. ему заводится сессия
2.1. сессия хранится на сервере, на клиенте только session-id, секретность этого айди в этом случае и является залогом секьюрити
2.2. сессия подписывается сервером и кладется в куку / локал стораж / жс-переменную клиенту. при каждом запросе проверяется валидность подписи
Ну так и есть.
AC
зачем и для чего вы тут токены протухающие начали изобретать?
Чтобы не крали сессии.
IG
Короче, если у тебя только веб, сделай проверку по куке