Аноны, помогите мыслями. Такая задача: есть сервис (фронт на вью) и апишка (бек на ларавел). Как мне сделать jwt авторизацию в данном случае? Погуглил и ничего путного по теме нет. Алсо, резонно ли вообще разделять так сервисы? Или проще все в один проект запихнуть?
>>2366709Гуглил плохо. Но авторизацию на jwt делать плохо. jwt хорош кода имеет короткий срок гидности и тебе не нужно рефреш токены всякие выдумывать.
>>2366746Аутентификации и авторизации точнее. Для авторизации однократных действий жвт подходит. Например схема с жвт авторизацией1) Фронтенд проходит обычную сессионную аутентификацию на ларке. У фронтенда есть кукисы что пользователь залогинен.2) Есть микросервис, который тоже торчит в интернет. Например отправка сообщений в телегу. Микросервис не должен позволять отправлять сообщения кому попало. Но микросервис сам не занимается авторизацией пользователя на отправку.3) Фронтенд говорит ларке дай жвт на отправку сообщения. Поскольку фронт аутентифицирован в ларкиной сессии, он получает жвт4) Фронтенд посылает команду микросервису отправить сообщение и дает ему этот жвт.5) Микросервис делает запрос ларке на проверку жвт. Если все ок то микросервис отправляет сообщение в телегу.6) Все этот жвт больше не нужен.
>>2369804Документация по bootstrap чем плоха? Там как раз готовые примеры кода, которые можно копировать.Что касается колонок, то что там копировать? Ты просто на глаз смотришь, сколько на сайте колонок, и делаешь столько же.>>2369673Без ООП и паттернов работы с БД за Ларавель браться нельзя. Это не фроеймворк для не знающих ООП или ORM.>>2366756Честно говоря, выглядит как антипример для микросервисов. Вместо того, чтобы слать все запросы на один и тот же бекенд, мы делаем несколько бекендов и количество запросов от этого увеличивается, а как и увеличивается шаткость и оверинжиниренность такой конструкции.Я думаю, что твой пример больше бы подошел для случая, когда один сайт дает другому разрешение что-то сделать. Иначе описанная тобой схема просто не имеет смысла.
