сколько вести объект юзера?

это несущественно

Гораздо лучше просто хранить все данные в БД

npm пакеты которые предоставляют сессии на куках хэшируют всё для безопасности

jwt и stateless сессии, нужны если у вас прям много микросервисов

чтобы не тратить время на ходьбу к авторизационному сервису

Микросервисы не имеют отношения к этому

Ну сколько можно повторять

Микросервисы - это реализация бэкэнда

ну я согласен

Фронтэнд не обращается к микросервисам напрямую

да

ну точнее он про это не знает

А jwt это вообще не нужная вещь

может и обращается

может и обращается

Нет

но ему должно быть все равно

Фронтэнд обращается к gateway

у тебя необязательно должен быть фронт-сервис, который все форвардит

jwt и stateless сессии, нужны если у вас прям много микросервисов

а кто говорил про стейтлесс сессии?

у тебя необязательно должен быть фронт-сервис, который все форвардит

Обязательно

нет

ну зачем?

Потому что есть вещи, которые нужно сделать на входе с каждым запросом

мне как раз нужно запоминать юзера, у меня не REST API а обычное SPA

а кто говорил про стейтлесс сессии?

если вы всю нужную инфу про сессию храните в токене или там в куке и гоняете ее, то она стейтлес, не?

Сессия не бывает стейтлесс

Потому что есть вещи, которые нужно сделать на входе с каждым запросом

прям вот с каждым?)

Сессия это и есть стейт

Сессия не бывает стейтлесс

собсно да

прям вот с каждым?)

Да, естественно

согласен

Сессия не бывает стейтлесс

ну под стейтлес мы подразумеваем, что вся инфа передается аргументом

хочется спросить тогда а что тогда стейтфул сессии

т.е. естественно она где-то хранится

Ну это назвается токен, обычно

хочется спросить тогда а что тогда стейтфул сессии

передаем токен, а бекенд по токену находит в базе инфу

или в памяти

т.е. либо вся инфа зашита в токен

А, ты имеешь в виду наоброт

либо по токену можно инфу получить

окей понял тебя

первое стейтлес, второе стейтфул

В jwt смысла вообще никакого нет

Тоже самое что куки: только хуже с безопасностью

А jwt это вообще не нужная вещь

не согласен, то тчо его оверъюзат - согласен

он нужен очень редко

Что он дает по сравнению с куками?

Да, естественно

а можешь пример привести?

jwt гут когда сервис чисто внутренний и можно забить на безопастность

Что он дает по сравнению с куками?

куки это ж способ хранения токена

Логгирование, авторизация, метрки

Куки это способ хранения чего угодно

Логгирование, авторизация, метрки

авторизация в разные сервисы по-разному идет, логирование соответственно тоже

Куки это способ хранения чего угодно

да

Нет, это неправильно

ну в смысле, в разные сервисы разные вещи ходят

Если это разные сервисы, то ты делаешь много разных сервисов, не связанных между собой

где-то нам нужен токен пользователя, где-то вообще девайса и пользователя, где-то только девайса

ребят, итого - есть какие-то реальные минусы менеджить сессию через куки?

Когда у тебя твое апи сделано в виде разных сервисов - это фейл сразу

Если это разные сервисы, то ты делаешь много разных сервисов, не связанных между собой

они все равно связаны, просто eventually

и еще вопрос, кто-нибудь юзал https://github.com/simov/grant ?

Когда у тебя твое апи сделано в виде разных сервисов - это фейл сразу

вопрос в разбиении

В общем, все что традиционно называется микросервисной архитектурой, подразумевает единый gateway

если ты поделил на выделенные контексты в рамках которых ходят транзакции, то вполне удобно

В общем, все что традиционно называется микросервисной архитектурой, подразумевает единый gateway

ага, чтоб это было не просто базвордом, а прям подходом, было бы хорошо)

ERROR: S client not available

Это абсолютно не имеет к микросервисам отношения, это что то другое, про что я никогда не слышал

Микросервисы всегда имеют единый gateway, в первую очередь по тому, что к микросервисам обычно идут от монолита

Постопенно монолит превращается в gateway

Микросервисы всегда имеют единый gateway, в первую очередь по тому, что к микросервисам обычно идут от монолита

этот единый gateway может быть просто nginx, в котором разные бекенды прописаны

Нет, это приложение

nginx это вообще мелкая деталь инфраструктуры

да, я про это же

смотрите вопрос

вот я авторизовался через твиттер

мне вот такое приходит

не пойму что мне с этим делать

зачем нужен аксесс токен

и аксесс сикрет

Юзай токен что бы слать запросы на твиттер

а если мне не нужно слать запросы на твиттер, мне просто надо чтобы люди могли залогиниться

через твиттер

я просто не до конца понимаю как это работает

я делал авторизацию свою раньше

тут всё понятно - создаешь пользователя сохраняаешь в базу

Ну так тебе пришел токен, по которому ты можешь получить почту юзера или просто использовать его Твиттер ид

потом при логине сверяешь пароли если совпал берешь этого юзера

Это абсолютно не имеет к микросервисам отношения, это что то другое, про что я никогда не слышал

смотри про что я: каждый микросервис это свой модуль, его связь(каплинг) с остальными должен быть минимален, иначе вообще нафига он нужен. Во вторых он должен сам мочь провести транзакцию, при этом синхронно с точки зрения клиента. У него могут быть какие-то побочки, которые выполнятся в будущем, обычно как раз через другие сервисы. В идеале микросервис это свой bounded context, в рамках которого живут связанные агрегаты, которые и являются границами транзакции

т.е. как мне например сохранять записи в базе ассоциированные с этим юзером

Да, но все это в рамках бэкэнда

мне все равно нужно в своей таблице юзеров создать для него запись

Все обращаения клиента имеют повышенные требования к авторизации, валидации, и т д

Да, но все это в рамках бэкэнда

ну так необязательно же

правильно?

Обязательно

т.е. как мне например сохранять записи в базе ассоциированные с этим юзером

Твиттер тебе просто подтверждает что юзер вошел

не могу понять почему тогда