Разве что в базу глянуть например

да брут вообще нигде не варик

эту авторизацию элементарно прикручивать, просто использовать и изменить если что, не вижу причины использовать jwt или oauth если можно сделать проще

разьве что oauth - это стандарт там все такое

О стандарте и идет речь

А что сложного в JWT? Вообще же очент просто

ребят, может вы напомните. Есть такой сервис, который готовые пакеты дает, типа лара+вуе+еще-что-то. Архив загружается и все готово для разработки

Вот прям что ж проще может быть

api_token))

Ну тоесть просто поле в таблице юзеров завести и туда записать?

@aleserche надо скилетоны готовые искать на гитхабе, так сложно вспомнить

@negasus да

для oauth там вообще штуки 3 что ли таблицы

ну тоже варинт, чо

для JWT не помню уже

я jwt пользую

для JWT не помню уже

нисколько

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

jwt токены же не надо хранить в бд

eeee

Вступление про куки

И про то что api не должен иметь состояния

Stateless

ну так то логично пока все)

Фолл

А ты jwt не юзал еще?

Нет

аа, ясн

Нет

Попробуй, рекомендую. Удивишься насколко просто и офигенно

мне пока негде

это как это О_о

Используя JWT можно избавиться от хранения токенов в базе

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

Нигде)

только на клиенте же

как это работает?

как апи понимает, что к ней тот юзер обратился

У тебя есть секретный ключ. ты формируешь токен, и в нем например записал id юзера.

Когда ты от юзера токен получил, ты его расшифровал своим ключом и получил id

и не только id там хранить можешь конечно

ассиметричное шифрование?

да, обратимое

хм

не уверен, что "ассиметричное" именно это значит

Алиса генерит два ключа, публичный и секретный. Отправляет Бобу публичный ключ, он с помощью него шифрует сообщение (например свой публичный ключ), отправляет Алисе. Зашифрованное публичным ключом сообщение можно расшифровать только с помощью секретного ключа (т.е. только Алиса может расшифровать мессагу)

это ты про ssh ключи

я это про ассиметричное шифрование)

ssh ключи просто работают на нем

ну это не то

а как тогда?

Клиент получит от тебя токен - тебе его и предявляет

клиент не знает,. что внутри токена

типо просто шифрование одним ключом?

ну это не то

а может и то, как посмотреть

да

лан, почитаю про jwt потом

все очень просто там

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.

RSA - ассиметричное скорей всего

Да сложного в целом то вообще в ларе ничего нет, прост опять же не вижу пока смысла использовать jwt если можно api token

Шифрование и расшифровка идет одним ключом

Jwt нужно ещё клиенту подключать

А апи токен ток на бэке

Да сложного в целом то вообще в ларе ничего нет, прост опять же не вижу пока смысла использовать jwt если можно api token

Ну в целом удобно, что 1) не надо в БД хранить, 2) срок действия легко контролировать и тт/д/

Да сложного в целом то вообще в ларе ничего нет, прост опять же не вижу пока смысла использовать jwt если можно api token

jwt то к ларе не имеет отношения)

Jwt нужно ещё клиенту подключать

чего чего?

Тьфу, фигню сморозил

ERROR: S client not available

Неужели никто не задавался вопросом нах придумали апи токен если есть куча готовых решений ?

Шифрование и расшифровка идет одним ключом

Это если симметричное шифрование. RSA (рекомендованное) это ассиметричное.

это с вики RSA

Это если симметричное шифрование. RSA (рекомендованное) это ассиметричное.

ассиметричное и круче в общем то

@negasus советую вникнуть в тему, интересно и пригождается довольно часто)

Ну в конексте JWT это не имеет смсла обсуждать

Так как клиенту ключ расшифровки не доступен

@negasus советую вникнуть в тему, интересно и пригождается довольно часто)

Я смысл понимаю

Ну в конексте JWT это не имеет смсла обсуждать

это дало мне представление о том, как оно работает

В jwt по моему ещё удобно - список прав можно запихнуть

Так как клиенту ключ расшифровки не доступен

jwt только в одну сторону работает типо?

В jwt по моему ещё удобно - список прав можно запихнуть

Туда можно записать инфу, а уж как ее расценивать - это детали

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

бля, непонятно чет)

jwt только в одну сторону работает типо?

Я ж говорю, сервер выдал клиенту токен. Все

Клиент тебе токен предъявляет, ты расшифровал - нужную инфу получил

Я ж говорю, сервер выдал клиенту токен. Все

ему (серверу) надо его где то хранить

нет

ват

токен внутри себя содержит нужную информацию

Заголовки тогда должны быть

Какие то

Или инфа об алгоритме шифрования

Ну блин, на гляньте на спецификацию, примеры посмотрите

Заголовки тогда должны быть

Так говоришь, будто их нету

https://github.com/lcobucci/jwt/tree/3.3

я вот этот пакет пользую

https://github.com/lcobucci/jwt/tree/3.3

Вот этот чувак только что и рассказывал тут

Или инфа об алгоритме шифрования

В токене все есть. Там 3 части, заголовки, данные и подпись. И инфа об алгоритме лежит в заголовках

кто-нибудь в курсе, постгря прощает лишние запятые в запросах?)