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

https://jwt.io/introduction/

Надо совсем Буратино быть чтоб не осилить jwt)

https://jwt.io/introduction/

Не, хочется услышать именно твоё понимание.

Я вот не доверяю тебе, как источнику. Чем ты докажешь свою проф пригодность в JWT?

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

так они все и написали

Считай это тест-драйвом технологии аутентификации

Не, хочется услышать именно твоё понимание.

Пейлоад это данные которые ты можешь в разумных пределах инжектить в токен

Пейлоад это данные которые ты можешь в разумных пределах инжектить в токен

Вредные данные? От злоумышленников?

Это может быть юзер ид, какие-то флаги рбак, айпи, юзернейм и тд

Вредные данные? От злоумышленников?

Што?

Вот у нас сейчас три объекта: мы (как сервер), пользователь и злоумышленник.

Мы должны проверить, что пользователь действительно пользователь, а не чувак, угнавший его данные.

Злоумышленник может эти поля подменить но он не сделает валидную подпись без секрета

Мы должны проверить, что пользователь действительно пользователь, а не чувак, угнавший его данные.

Данные подписаны, если злоумышленник не знает ключа, он ничего не подделает.

А значит на бэкенде этот токен отбросится

Сейчас он скажет, что злоумышленник уже побывал на бекенде, и взял там ключ.

И что ты сделаешь тогда, а?!

Сейчас он скажет, что злоумышленник уже побывал на бекенде, и взял там ключ.

Ага, и приватный ключ от сертификата.

видимо ушел читать

Мы пользователю что отдаём?

Это ты нам скажи

мы что, учить тебя будем.

видимо ушел читать

Да, я не против. Всегда нужно иметь под рукой оригинал. Кто я по твоему: человек или машина?

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

Не, я про то, что вы тут бъёте на то, что IP можно не проверять при наличии JWT

С чего бы

давайте закроем тему джевете)

ИП можно проверять в дополнение к проверке валидности токена

давайте закроем, и откроем тему PHPSSID

ИП можно проверять в дополнение к проверке валидности токена

когда рефрешим))

И проверять не просто айпи, а например asnum и выше упомянутый fingerprint

Токен или ключ или фингерпринт пофиг. Секрет на сервере шифрует и отправляет пользователю что-то для дальнейшей его аутентификации по токену.

Но принадлежит ли токен пользователю или этот токен уже у кого-то?

Не, я про то, что вы тут бъёте на то, что IP можно не проверять при наличии JWT

Если не проверять IP при запросе, то его и не нужно записывать в токен. Если нужна такая проверка, то клади в токен.

ИМХО IP помогает в данной ситуации.

Тогда IP все же нужно проверять на стороне сервера. А не принимать на веру в токене со тороны клиента.

Ему и не нужно. Он заберет всю подпись и будет ей пользоваться прикинувшись клиентом.

Злоумышленник может эти поля подменить но он не сделает валидную подпись без секрета

Ему и не нужно. Он заберет всю подпись и будет ей пользоваться прикинувшись клиентом.

Как? Если идёт проверка IP.

Так что без проверки IP ты слит.

Как? Если идёт проверка IP.

А это не я сказал. Alexey Samoylov, [09.09.18 13:20] ИП можно проверять в дополнение к проверке валидности токена

В дополнение читать как не обязательно

Как? Если идёт проверка IP.

Не я спорю против всех. )

А это не я сказал. Alexey Samoylov, [09.09.18 13:20] ИП можно проверять в дополнение к проверке валидности токена

Так выше же обсуждали, можно проверять только при важных операциях, например при смене пароля, просмотр личных данных и т.д.

Я Шнайдера читал. Там все варианты описаны. Рекомендую для понимания JWT и токенов в сессиях. И сертификатов с ключами. И даже клиентских сертификатов, как замену токенов и сессий.

Так выше же обсуждали, можно проверять только при важных операциях, например при смене пароля, просмотр личных данных и т.д.

Да, это я и писал выше. Внимательнее перечитай )

И проверять не просто айпи, а например asnum и выше упомянутый fingerprint

а можно про asnum пару слов, или ссылку почитать. мне для этого провайдер геоайпи нужен?

а можно про asnum пару слов, или ссылку почитать. мне для этого провайдер геоайпи нужен?

Geoip2 даёт эту инфу

Токен или ключ или фингерпринт пофиг. Секрет на сервере шифрует и отправляет пользователю что-то для дальнейшей его аутентификации по токену.

секрет ничего не шифрует. шифрование и кодировка разные вещи

кстати, а как вы фингерпринт делаете? без сторонних модулей (тот что на гитхабе весит порядка 50 кб кажется, и вообще он мутный)

просто уа+айпи в хеш?

кстати, а как вы фингерпринт делаете? без сторонних модулей (тот что на гитхабе весит порядка 50 кб кажется, и вообще он мутный)

Вот с помощью той всей мути он создаёт уникальный ключ на пользователя. В 80% случаев. Но браузеры урезают различные апи и методы, т.к. что уникальность падает

Лучше чем та библиотека по создаю фингерпринта ничего нет

https://m.habr.com/post/418527/

Лучше чем та библиотека по создаю фингерпринта ничего нет

имхо, слишком дорогая зависимость. у меня вообще сторонних пакетов по минимуму

имхо, слишком дорогая зависимость. у меня вообще сторонних пакетов по минимуму

Ну вытащи оттуда нужные способы

кто нибудь делал авторизацию через модалку, а не через отдельные рауты? мне вот нравится такой UX, хочу попробовать

ERROR: S client not available

кто нибудь делал авторизацию через модалку, а не через отдельные рауты? мне вот нравится такой UX, хочу попробовать

Причем тут модалка Логику авторизации где угодно можно использовать

кто нибудь делал авторизацию через модалку, а не через отдельные рауты? мне вот нравится такой UX, хочу попробовать

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

при чем тут сервер))

тут порядок действий юзера совсем другой на клиенте

соответственно и структура роутов

а еще видел что некоторые сайты имеют оба варианта - и через модалку и отдельный раут

у тебя бизнес логика авторизации это отдельный модуль

он не привязан к UI

так что какая разница в каком компоненте ты будешь ее вызывать?

какая кореляция между формой авторизации и ее логикой в зависимости от ее расположения по роуту?

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

и вообще каждый компонент напоминает небольшой мусорник

и вообще каждый компонент напоминает небольшой мусорник

Мое первое впечатление когда я увидел жсх + логику + стайледы в одном файле

В реакте

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

c ui-kit ами которые пытаются решить все проблемы всегда так

независимо от фреймворка

В реакте

не знаю в реакте я открываю свой старый проект - почти мгновенно вспоминаю что к чему

например компонент какой нибудт хуйни вроде чекбокса весом 50кб в итоге

А потом посмотрел на редакс) ну и все сразу стало понятно чо к чему ...s

Мое первое впечатление когда я увидел жсх + логику + стайледы в одном файле

?

?

А потом я начал писать так же на вью

А потом я начал писать так же на вью

Во вью тоже все в одном файле ?

Во вью тоже все в одном файле ?

Но jsx лучше

Обьективно

Но jsx лучше

Не

+

Мне не зашло

Мне не зашло

Ну мне вначале тоже. Проблевался 500 раз

Ну мне вначале тоже. Проблевался 500 раз

Логика + разметка в одним месте