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