Виталий Хоменко, да собственно писалось уже. Если запрос идет не с того IP то берем и просто игнорим - это вообще не проблема. Т.к. токен в данном случае сразу становится не валидным. Если же пришел запрос с того же адреса что и ожидалось - то у пользователя проблемы намного бОльшие чем просто уведенный аккаунт. Да, в компаниях технически оно может стать проблемой, т.к. все выходят через один и тот же адресс, но... это извините, уже проблемы компании которая у себя такое допустила.
Просто стоит понимать что есть безопасность, а есть - избыточность. Вам нужно обеспечить безопасность своих данных, а не подтирать за пользователем везде где можно и совсем не нужно.
Нужно понимать, что JWT создавался что бы не делать кучи лишних "чихов" в БД. Т.е. рассматривать его имеет смысл именно в рамках больших сервисов с большим количеством запросов в секунду. Для мелких - этот вопрос не стоит так остро, можно и сделать дополнительный запрос в БД.
Два разных клиента одной парой токенов пользоваться не могут - собственно по причине того что там IP прописан, да и RefreshTokenID мы туда тоже пихаем. В итоге всегда можно увидеть с какой "сессии" шли запросы. в ЛК пользователя есть список подобных токенов, их можно просто отозвать. Но если у нас срабатывает ситуация что приходит не валидный access токен, мы просто сообщаем что он не валиден. Далее уже сам клиент должен запросить создание нового подобного токена. Если и эта операция не успешна - тогда уже потребуется вводить логин-пароль для получения валидного Refresh токена.
Да, можно конечно взломщику все это проигнорить и продолжать слать не валидный access/refresh токен, но... толку то с того? N подобных запросов в течении минуты - и мы отзываем Refresh токен автоматиечки и отправляем на почту клиента уведомление что подобное происходит, дальше собственно уже не наша забота. Можно вообще аккаунт временно блочить если подобный функционал написан. Вариантов масса. Тут просто надо понимать что JWT - не панацея. Как собственно и любые куки и сессии. Надо понимать что JWT в первую очередь создавался что бы снизить нагрузку на БД при большом гарантированном количестве запросов от клиентов. В итоге, мы, используя JWT можем делать не ~5к запросов в секунду в БД, а всего в среднем около 20, что согласитесь, намного меньше)
В ситуации с хищением Access JWT токена при наличии в нем того же IP адреса(даже если он динамический) не происходит ровным счетом ничего. Точнее происходит - запрос нового токена со стороны сервера т.к. этот недействительный. Итого - ломатель ничего не достигает. Если же у вас там и запрос пришел с клиентского IP - то у клиента проблемы явно серьезней чем уведенный токен.
Единственное что может быть не очень - так это передавать IP например в открытом виде. Ну так его то как раз можно и зашифровать, все равно при проверке его можно просто зашифровать еще раз и сравнить. Но - это уже относится к проверке валидности самого токена.
xmoonlight, А можно пожалуйста не спамить сообщениями? Спасибо!
Далее, клиентские библиотеки видимо имелись в виду именно как работающие в "браузере". Естественно если подписывать JWT в браузере - клиент сможет сделать с ним всё что угодно.
Впредь прошу ваши "не оценочные" мнения поддерживать ссылкой на официальное пояснение документации JWT.
P.S. Используем JWT, храним в куках. Используем в варианте Refresh & Access ключей, т.е. клиенту отдается два токена. Refresh используется для получения Access и только этого. Access живет пару минут и хранит "общие" данные клиента который могут потребоваться внутренним сервисам чаще всего и которые не являются "приватными" и "закрытыми". Т.е. UserID, Login, и т.п. вещи. Он же используется для проверки что пользователь авторизован.
Tyranron: Вот за диаграмму - просто огромнейшее спасибо! честно говоря даже мысль не появилась что подобное существует...(
Обязательно изучу. Теперь думаю тоже смогу разобраться как там что устроено :)
Tyranron: вооот :) но я понял - смотрим на Forward. Просто не смотрел на него т.к. считал что т.к. используется нат - правила фильтров уже не сработают. Но посмотреть - посмотрю. Если заработает - будет замечательно :)
Tyranron: понятно, т.е. пускаем контейнеры через --network=host и не имеем проблем? Обязательно попробую.
Про FORWARD тоже попробую, спасибо за направление :)
123459: Видел конечно, первая ссылка - там мак, и в принципе и так понятно что это не стандартный путь где он смотрит. Но в Path он у меня добавлен, как еще заставить его искать в той папке - я не понимаю.
Вторая ссылка - там ответа так и нет.
весь прикол в том, что вообще нет правила которое бы показывало что надо слушать 9000 порт.
ОС сама может решить что если внешний ИП равен тому, на который я хочу попасть то обращаться по локальному? Потому что я просто не уверен что оно вообще уходит на микротик... ну или микротик сам заворачивает всё обратно... но я не понимаю почему это происходит...
Вениамин Смирнов: спокойно можете размещать если там такое действительно есть. А что бы глупых вопросов не было - это вообще можно разместить вместе со ссылкой на страничку откуда вы его взяли.
deadw00d: Тогда попросите составить вам схему того, у кого этих проблем нет, ну или решайте свои проблемы :) bootswatch - это "сделать на скорую руку", а так - вам в кастомизатор.
Сергей Зеленский: как я не люблю людей которые даже не смотрят что им пишут. kimsufi дает возможность пользовать серверы с 5 евро, да они слабенькие, но для сайтов - их хватает вполне. И да, сервер - не обязательно физическая железка, сервер может быть и виртуальным, посмотрите, сами написали - vdS, да и на ресурсах что я дал есть и дедики и вдсы, а вы опять это не посмотрели. Надоело уже с вами общаться, вы - не автор темы, еще какие-то претензии предъявляете.
Сергей Зеленский: вот только передергивать не надо. Человек ясно сказал что держит несколько сайтов. Это уже достаточная причина задуматься о сервере вместо хостинга.
Задача простая, есть строка, в ней могут быть буквы, цифры и некоторые символы, мне нужен поиск строки по подстроке аналогичный mysql like "%es%" который вернул бы мне test
Эм... а если там изменения могут быть как тогда поступать? с одной стороны - я могу просто дропнуть лишнюю табличку при необходимости, а тут придется удалять только определенное количество строк, а значит - это время которое будет на это тратиться. И это сильно больше чем просто удаление самой таблицы..
Просто стоит понимать что есть безопасность, а есть - избыточность. Вам нужно обеспечить безопасность своих данных, а не подтирать за пользователем везде где можно и совсем не нужно.
Нужно понимать, что JWT создавался что бы не делать кучи лишних "чихов" в БД. Т.е. рассматривать его имеет смысл именно в рамках больших сервисов с большим количеством запросов в секунду. Для мелких - этот вопрос не стоит так остро, можно и сделать дополнительный запрос в БД.
Два разных клиента одной парой токенов пользоваться не могут - собственно по причине того что там IP прописан, да и RefreshTokenID мы туда тоже пихаем. В итоге всегда можно увидеть с какой "сессии" шли запросы. в ЛК пользователя есть список подобных токенов, их можно просто отозвать. Но если у нас срабатывает ситуация что приходит не валидный access токен, мы просто сообщаем что он не валиден. Далее уже сам клиент должен запросить создание нового подобного токена. Если и эта операция не успешна - тогда уже потребуется вводить логин-пароль для получения валидного Refresh токена.
Да, можно конечно взломщику все это проигнорить и продолжать слать не валидный access/refresh токен, но... толку то с того? N подобных запросов в течении минуты - и мы отзываем Refresh токен автоматиечки и отправляем на почту клиента уведомление что подобное происходит, дальше собственно уже не наша забота. Можно вообще аккаунт временно блочить если подобный функционал написан. Вариантов масса. Тут просто надо понимать что JWT - не панацея. Как собственно и любые куки и сессии. Надо понимать что JWT в первую очередь создавался что бы снизить нагрузку на БД при большом гарантированном количестве запросов от клиентов. В итоге, мы, используя JWT можем делать не ~5к запросов в секунду в БД, а всего в среднем около 20, что согласитесь, намного меньше)