Надо срочно понять

В Sentry прям жестко указан лимит сообщения в 1000 символов?

Нет времени разбираться, просто у меня INFO с данными запроса и INFO с данными ответа - не влезает

.D

\Raven_Client::MESSAGE_LIMIT

2:

Raven_Util::set($options, 'message_limit', self::MESSAGE_LIMIT)

Кто нибудь использовал fractal для сериализации различных выборок в json формат. Или это лишний оверхед и serializer symfony вполне достаточно?

@fes0r вроде топил за фрактал

@fes0r вроде топил за фрактал

да, топил. сейчас уже не так активно

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

ну мол.... если у тебя active record то фрактал вообще хорошо

а так... есть вопросы

Кто нибудь использует у себя на проект аутентификацию с использованием jwt? Мне интересен вопрос, как организвать выход с нескольких устройств или блокировку токена. Пока думаю при логине записывать так же токен в redis или memcahed типо: auth:[user_id]:token и проверять если такой токен если нет значит бросаем на страничку входа и для этого будет необходимо реализвать свой кастомный провайдер аутентификации (токен, листенер, фабрику). И еще интересует refresh токен. Я правильно понимаю, что если человек пришел с истекшим jwt токеном, то мы идем ищем его в базе и если есть refresh токен, то генерируем новый access?

зачем что-то хранить в базе и использовать jwt?

сам по себе jwt - это фактически хранилище информации

могу ошибаться - но по-моему совмещать нет смысла - используй любой ИД для токена и храни в базе тогда все

Кто нибудь использует у себя на проект аутентификацию с использованием jwt? Мне интересен вопрос, как организвать выход с нескольких устройств или блокировку токена. Пока думаю при логине записывать так же токен в redis или memcahed типо: auth:[user_id]:token и проверять если такой токен если нет значит бросаем на страничку входа и для этого будет необходимо реализвать свой кастомный провайдер аутентификации (токен, листенер, фабрику). И еще интересует refresh токен. Я правильно понимаю, что если человек пришел с истекшим jwt токеном, то мы идем ищем его в базе и если есть refresh токен, то генерируем новый access?

тут много вариантов

вопервых стоит определиться зачем тебе refresh токены

обычно их используют для усложнения MITM атак

ну мол кто-то перехватил токен и это может быть только на определенное время

другой вариант зачем нужны рефреш токены - если нет другого способа инвалидировать сессию.

Есть, должен быть.

использовать же рефреш токены для инвалидации сессиий по времени - не очень затея

лучше организовать блэк лист для инвалидации нужных токенов

Если у пользователя крадут пару токенов то хакер зарефрешит у себя и пользователь останется неавтортзован Далее он авторизовывается и инвалидная пара у хакера уже

Думаю что-то все таки хранить надо

Но не уверен

Думаю что-то все таки хранить надо

зачем хранить токены все если тебе нужно только иметь возможность инвалидировать оные?

и не все а лишь часть

зачем хранить токены все если тебе нужно только иметь возможность инвалидировать оные?

Каким образом инвалидировать, помимо expired on в самом токене?

зависит от задачи. В большинстве случаев мне надо инвалидировать все сессии пользователя

а это значит что я просто добавляю ID нужного пользователя в блэклист

ну то есть в JWT у нас есть время выдачи токена, время действия, есть идентификатор пользователя

это дает тебе возможность реализовать самые разные механизмы инвалидации

А как инвалидтровать пару жвт и рефреш?

с рефрешами все просто - тебе сервер аунентификации просто не выдаст новый токен

рефрешы у тебя в базе хранятся

а вот jwt - просто не пускаешь, кидаешь 401

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

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

Ну так как я инвалидирую то его

Ну так как я инвалидирую то его

перечитай еще раз что я написал.

Перевариваю про блек лист

тебе придет запрос с JWT для пользователя в блэк листе сессиий. Например мы добавили правило "считай невалидными все JWT токены этого чела которые он получал до такого-то времени"

и если твой токен подпадает под правило - просто не пускаешь дальше

а поскольку блэклист у тебя будет относительно небольшим (малый процент всех пользователей)

то как бы нет проблем

Такая ситуация. Пользователь прошел аутификацию, авторизовали его Хакер украл пару Через 5 минут хакер рефрешнул себе пару Пользователь заново недоумевая аутифицируется и авторизовывается Вопрос как инвалидировать пару у хакера не трогая пару пользователя

и как ты собрался это инвалидировать?)

ну то есть

по другому

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

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

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

если у него внезапно поменялся IP это может быть по вполне обычным причинам

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

Не можем. Сервер с api другой для него это свежие запросы он не в курсе что аунтификация была с другого айпи

Не можем. Сервер с api другой для него это свежие запросы он не в курсе что аунтификация была с другого айпи

когда происходит рефреш - ты узнаешь IP

можно еще по юзерагенту сверять

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

Ну вот надо) вроде как то возможно, надо поизучать

когда происходит рефреш - ты узнаешь IP

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

ERROR: S client not available

можно еще по юзерагенту сверять

Так же как и айпи не можем

Ну вот надо) вроде как то возможно, надо поизучать

это зависит от задачи.

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

другие сервера не знают о рефрешах

ну и ты можешь прямо в JWT записать какому IP ты доверяешь

что бы зафорсить рефреш в случае смены IP

все очень от задачи зависит

@fes0r А какой флоу при использовании refresh токена. Приходит пользватель => истек срок => достаем id пользователя => ищем в базе, если есть то новый токен? Но что будет если кто-то перехватил токен => тогда держим его в блэклисте и при рефреше проверяем токен?

эм...

если jwt истек - клиент отправляет запрос с рефреш токеном на получение нового

рефреш токены хранятся в базе, это просто набор рандомных байт

Но на клиенте не хранится рефреш

так что ты не по ID юзера достаешь а по токену

Но на клиенте не хранится рефреш

хранится

при атворизации ты получаешь пару токенов

jwt + refresh

во всех запросах юзаешь только jwt

для получения нового jwt юзаешь только refresh и получаешь новую пару

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

@fes0r Спасибо. Наконец-то понял)

Рефреш нужен для auth сервера для обновления пары при истечения expiredOn

это зависит от задачи.

Это вообще универсальный ответ. Очевидно не просто же так спрашиваю)

ну и ты можешь прямо в JWT записать какому IP ты доверяешь

Вот это интереснее спасибо

А как быть в случае аутентификации с различных устройств, если refresh меняется?

Это вообще универсальный ответ. Очевидно не просто же так спрашиваю)

но задачу то я не знаю)

А как быть в случае аутентификации с различных устройств, если refresh меняется?

несколько refresh токенов

ну то есть типа как "несколько сессий"

а вообще лайфхак - берешь auth0 и делаешь все на нем)

5 баксов в месяц каких и у тебя там все, и инвалидация сессий, и управление сессиями пользователей, и восстановление пароля

правда ли что функционал баднлов удалят из симфони?

если я делаю монолитное приложение достаточно использовать AppBundle для проекта?