«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2022/05/29 19:25:18  №2366709 1
Аноны, помогите мыслями. Такая задача: есть сервис (фронт на вью) и апишка (бек на ларавел). Как мне сделать jwt авторизацию в данном случае? Погуглил и ничего путного по теме нет. Алсо, резонно ли вообще разделять так сервисы? Или проще все в один проект запихнуть?
Ответы: >>2366716 >>2374449
Аноним 2022/05/29 19:37:22  №2366716 2
>>2366709
Гуглил плохо. Но авторизацию на jwt делать плохо. jwt хорош кода имеет короткий срок гидности и тебе не нужно рефреш токены всякие выдумывать.
Ответы: >>2366738
Аноним 2022/05/29 20:28:06  №2366738 3
>>2366716
Лучше бы по теме сказал что-нибудь
Ответы: >>2366746
Аноним 2022/05/29 20:37:29  №2366746 4
Ответы: >>2366756
Аноним 2022/05/29 21:01:34  №2366756 5
>>2366746
Аутентификации и авторизации точнее. Для авторизации однократных действий жвт подходит. Например схема с жвт авторизацией
1) Фронтенд проходит обычную сессионную аутентификацию на ларке. У фронтенда есть кукисы что пользователь залогинен.
2) Есть микросервис, который тоже торчит в интернет. Например отправка сообщений в телегу. Микросервис не должен позволять отправлять сообщения кому попало. Но микросервис сам не занимается авторизацией пользователя на отправку.
3) Фронтенд говорит ларке дай жвт на отправку сообщения. Поскольку фронт аутентифицирован в ларкиной сессии, он получает жвт
4) Фронтенд посылает команду микросервису отправить сообщение и дает ему этот жвт.
5) Микросервис делает запрос ларке на проверку жвт. Если все ок то микросервис отправляет сообщение в телегу.
6) Все этот жвт больше не нужен.
Ответы: >>2374424
Аноним 2022/06/07 21:30:15  №2374424 6
>>2369804

Документация по bootstrap чем плоха? Там как раз готовые примеры кода, которые можно копировать.

Что касается колонок, то что там копировать? Ты просто на глаз смотришь, сколько на сайте колонок, и делаешь столько же.

>>2369673

Без ООП и паттернов работы с БД за Ларавель браться нельзя. Это не фроеймворк для не знающих ООП или ORM.

>>2366756

Честно говоря, выглядит как антипример для микросервисов. Вместо того, чтобы слать все запросы на один и тот же бекенд, мы делаем несколько бекендов и количество запросов от этого увеличивается, а как и увеличивается шаткость и оверинжиниренность такой конструкции.

Я думаю, что твой пример больше бы подошел для случая, когда один сайт дает другому разрешение что-то сделать. Иначе описанная тобой схема просто не имеет смысла.
Аноним 2022/06/07 21:38:13  №2374449 7
>>2366709

Насчет разеделения на фронтенд-бекенд: это зависит от того, какой у тебя сайт. Если ты сам не понимаешь, зачем нужно разделять, то наверно в твоем случае это не нужно.

То есть, никто не начинает писать фронтенд на вью потому, что это модно. Обычно для этого есть какая-то важная причина.

Например, ты пишешь приложение для подбора цветовых схем и без использования вью получается куча лапши, которую ты хотел бы упростить за счет грамотного применения архитектуры MVC и data-binding. Даже в этом случае, возможно, что ты сделаешь не все приложение на SPA, а лишь интерактивный блок с редактором схем.

> Как мне сделать jwt авторизацию в данном случае?

При логине фронтенд отправляет на бекенд запрос на авторизацию. В запросе содержится логин и пароль. В ответе от сервера приходит JWT токен с содержимым вроде { "id": id пользователя, "issued": время выдачи }.

После этого фронтенд добавляет этот токен во все запросы, которые требуют авторизации.

Никакого рефреша не нужно. Если ты хочешь, чтобы пользователь никогда не перелогинивался, то разрешаешь использовать токен вечно. Если хочешь чтобы он логинился заново каждый месяц, то ставишь соответствующее ограничение и отказываешься принимать слишком старый токен.