SZ
Спрашивай, спрашивай :)
Мы тут не холиварим
Мы тут не холиварим
Size: a a a
2021 August 12
SZ
Так а если мы тут вдруг взяли и инвалидировали на сервере всю сессию, а токен у клиента уже подписан. Как сервис 2 узнает, что надо такого клиента слать нахер?)
DF
всегда можно спросить валиден ли еще токен у сервиса 1 :)
SZ
Ну так и возвращаемся к вопросу: нахера тогда вообще токены? Если на каждый запрос придется спрашивать где-то, валиден ли он. Вся суть токенов в том, чтобы как раз избавиться от таких вопросов в ущерб надёжности (в ущерб возможности резко оборвать сессию)
VO
да как обычно, только в обратном порядке -- клиент приходит на сервис2, тот отправляет на сервис а с параметром куда потом редирект сделать. редирект приходит с сессионной кукой например, сервис 2 в базе смотрит эту куку. нашел -- хорошо. не нашел -- пошел опять на сервис а.
да тысячи разных вариантов есть.
да тысячи разных вариантов есть.
VO
нет конечно. чего хорошего в том, что я не могу в интернет выйти?
c
по коллбеку
SZ
А что он получит в этом коллбеке, какую информацию? И что должен будет с ней сделать?
c
что сессия юзера всё, инвалидировать на своей стороне
c
для этого, как минимум, сервера должны быть под одним доменом и иметь общие ключи
SZ
SZ
Это если идентификатор клиента сувать в куку. А можно и не в куку
VO
нет, не должны. куку не обязательно в куке передавать
c
если вопрос - нахера JWT, то ответ был - для доверенной передачи авторизационной информации между сервисами. Спрашивать на каждый запрос - валиден ли токен - не нужно.
c
тогда возвращаемся на шаг назад - клиент сходил за авторизацией - что он там получил?
c
И с чем он идёт уже авторизованный к первому сервису?
VO
redirect
VO
с urlом
c
Окей, что в урле? Откуда Сервис 1 знает, что реквесту можно верить?
VO
в базе сессию посмотрит