Anonymous
Пока юзер опять не даст свои данные, те пароль
Illya
приходит новый токен - нам все равно надо запрос в хранилище делать
Anonymous
После этого запросов не будет за идентификатором, пока он опять не запросит логаут
Illya
а раз делаем запрос в хранилище - это ничем не лучше сессий
Anonymous
приходит новый токен - нам все равно надо запрос в хранилище делать
Откуда новый токен придет?
Illya
от пользователя
Anonymous
Так мы говорим о логауте второго устройства, там старый токен
Illya
еще раз: как только у нас в сценарии - нам прислали токен - нам надо куда-то постучаться - этот сценарий ничем не лучше сессий
Anonymous
Со старым идентификатопом
Anonymous
Ок. Надо видео посмотреть, может всё проще
Denis
Тыж ае дижитал - с этого надо начинать )))
Anonymous
Не ищу лёгких путей)))
Roman
стойте... вы токенами как ключами сессий пользуетесь? но это-ж как-бэ неправильно?!
Illya
не как ключами сессий )
Illya
вы хотите нам рассказать что токены - это и есть по сути сессия, которая несет в себе все нужные данные?
Illya
;)
Roman
вы хотите нам рассказать что токены - это и есть по сути сессия, которая несет в себе все нужные данные?
можно конечно и так, но обычно так никогда не делал
Illya
ок, что вы хотели сказать?
Denis
Файт
Anonymous
Токены для сессий моветон
Roman
я краем глаза быстро перелестал сообщения... токены же нам позволяют легче масштабировать по горизонтали, поскольку всё что нам нужно для того чтоб убедиться в верности токена это приватный ключ... плюс можно сразу UserId в нём хранить and this scales very well.. но проверка при каждом запросе некого центрального storage'а отозванным токенов как бы противоречит этому..
Roman
но... если например некий cache на каждом сервере хранить то должно шустро работать... т.е. не в центральном месте отозванные токены хранить, а просто при отозвании синкать на все серваки
Anonymous
Комменты на Ютубе зачет
Denis
Ты - ужасный фантазер )))
Anonymous
я краем глаза быстро перелестал сообщения... токены же нам позволяют легче масштабировать по горизонтали, поскольку всё что нам нужно для того чтоб убедиться в верности токена это приватный ключ... плюс можно сразу UserId в нём хранить and this scales very well.. но проверка при каждом запросе некого центрального storage'а отозванным токенов как бы противоречит этому..
Кто тут предлагает проверять при каждом запросе?
Roman
Кто тут предлагает проверять при каждом запросе?
ну когда токен перехватили мы хотим его "отозвать", типа этот токен не принимать
Roman
и хранить его надо пока в нём поле expired не устареет
Roman
ибо после можно уже спокойно удалять, система и так его не возьмёт
Anonymous
А как ты отзывать предлагаешь?
Roman
но это-ж тогда каждый при каждом запросе нужно стор отозванных пероверять
Illya
похоже люди не понимают простую идею: любой централизованный запрос равносилен запросу за сессией
Anonymous
А кто тут про блеклист говорил???
Illya
а поверьте - сессии с key-value storage работают тоже мегабыстро :)
Roman
А как ты отзывать предлагаешь?
я лишь один коментарий добавил: нужно не центральный стор дёргать, а лучше на каждый сервер синкать, ибо так horizontal scalability не нарушается
Denis
Это твой коммент под видео?
Denis
)))
Anonymous
Не надо ничего синкать это против сути токенов
Roman
Не надо ничего синкать это против сути токенов
если ты хочешь токен "отозвать", то увы... никак иначе..
Anonymous
При чем тут синк
Roman
иначе если токен перехватят то пока expired поле не устареет - серверы его будут принимать
DreaMinder
Если делать запрос за юзером на каждый чих, дело только в лишнем запросе и задержке на него?
Anonymous
Roman
Хм... Тут я задумался
это на самом деле преимущество сессий, их можно отозвать одним кликом мол "Logout from device". Токены такое по сути тоже могут, но не по умолчанию
DreaMinder
Или "раз делаешь запрос то лучше бы сделал на сессиях как нормальные люди"?
Anonymous
иначе если токен перехватят то пока expired поле не устареет - серверы его будут принимать
Это ж точно. Тогда моя тема сверять идентификатор не катит, если только не давать эту команду всем серверам
Anonymous
Или "раз делаешь запрос то лучше бы сделал на сессиях как нормальные люди"?
Речь об отдельном домене же
Roman
сессии они в том плане хуже, что тут всегда идёт проверка центрального стора, а это не очень хорошо масштабируется, грубо говоря у тебя 1000 API серверов и один центральный session storage, который за-DoS'ить не проблема))
с токенами всё проще, нет центрального стора, у каждого сервера приватный ключ и это всё что ему нужно. Обычно в токен мы помещаем время его expiry и userId. Каждый сервак в таком случае может идентифицировать клиента самостоятельно и это супер, а вот для того чтоб сессии завершать - можно хранить некий black-list отозванных токенов, но тогда лучше на каждом серваки, чтоб опять не вводить центральный стор как в сессиях
Oleh
а что мешает использовать разные сторы?
Oleh
там где разные токены
Oleh
где обычно хранят токены сесий? знаю к примеру redis
Denis
Файлы
Oleh
я об серверсайд
Denis
Прямо в названии я видал
Denis
Я бэк
Oleh
об каких файлах идет речь?
Denis
Ща
Oleh
с помощью redis делают счетчик количества реквестов в секунду, значит он довольно шустрый
in memory же
Roman
однако с WebSocket'ами на самом деле можно решить проблему ещё элегантнее: ибо с сокетами аутентификация происходит лишь 1 раз при создании связи, а при обработке API call'ов уже не нужно проверять идентификацию, ибо мы мапим userId на fileDescriptor (т.е. идентификатор подключения) и по умолчанию знаем кто откуда 🙂
Сокеты можно с сессиями использовать, ибо теперь API не дёргает при каждом API call'е центральный стор, нагрузка намного меньше. И отозвать сессию можно очень просто, удаляем сессию из стора, обрываем связь сокета, вуаля!
WebSocketsSecure + Sessions = 🕶
Oleh
нечего не говорит
Denis
Искоропки лара там хранит
Denis
Чем плохо?
Anonymous
Anonymous
👍
Anonymous
Кот случайно
Oleh
ну в продакшн такой вариант не идет, нужно будет постоянно делать запрос на диск и это не оптимизируется не как
в бд используются умные алгоритмы которые сводят запросы к бд к минимуму
Denis
Но бд на диске тоже
Denis
Тут файл даже не читается
Victor
как по мне идея интересная
Victor
хранить сешены в файлах
Denis
Ну это стандартная практика
Denis
Просто если хранить в базе то при разрастании таблицы может резко упасть перформанс
Denis
Так было у меня на модыкс