AD
короче от требований зависит
Size: a a a
2020 April 09
DS
Отличный вопрос, посоны говорят надо иметь что-то вроде таблицы для блеклистинга, но а почему не зашить в токен еще и короткое время жизни?)
оно по умолчанию же есть там
AD
Отличный вопрос, посоны говорят надо иметь что-то вроде таблицы для блеклистинга, но а почему не зашить в токен еще и короткое время жизни?)
а сколько ты поставишь время жизни?
DS
тут другая проблема, с секюрити все еще терпимо. как жить ,если ты зашиваешь роль в токен, а потом эту роль менять решил. т.е. надо подумать как токен обновлять или экспайрить грамотно
вообще, тут разве не стоит оценить как часто вообще меняются роли?
DS
от этого и время будет зависеть
PK
а сколько ты поставишь время жизни?
Зависит от требований, я бы отталкивался от статистики изменений прав.
PK
В любом случае даже если сделать блэклист для отозванных токенов, то это скорее всего будет гораздо быстрее, чем например постоянно проверять права в базе.
DP
Единственное применение я смог придумать для всего это (я тестировал скорости и все такое для своих проектов), это если все клиенты на gprs (горы например, или Марс-Луна). Во всех остаальных случаях смысла нет для jwt. Идея красивая, но бесполезная в современных условиях.
AD
Зависит от требований, я бы отталкивался от статистики изменений прав.
собственно да, но в любом случае, если у тебя будет TTL может возникнуть ситуация, когда у пользователя уже новая роль, но код работает для старой. иногда это критично, иногда нет
AD
мне нравится вариант решения проблемы с API gateway в который можно заэкспаирить токен для определенного пользователя по событию
AG
https://blog.indrek.io/articles/invalidate-jwt/
Поддерживаю автора статьи. Но если бы у меня была такая задача - инвалидировать jwt, то я бы скорее всего выбрал черный список на редисе.
(если позволяет архитектура приложения, ведь может оказаться, что токены выдаются каким-то сервисом, к которому нет доступа)
Поддерживаю автора статьи. Но если бы у меня была такая задача - инвалидировать jwt, то я бы скорее всего выбрал черный список на редисе.
(если позволяет архитектура приложения, ведь может оказаться, что токены выдаются каким-то сервисом, к которому нет доступа)
2020 April 10
NB
Тут вроде так и делают
DB
Всем привет. Можете подсказать есть ли возможность собрать контейнер, который можно отдавать клиентам типа как селф-хостел решение без доступа с их стороны к содержимому контейнера ?
Может какая-то магия с настройкой пользователей и групп или ещё что-то невиданное?
Может какая-то магия с настройкой пользователей и групп или ещё что-то невиданное?
PK
Если ты что-то отдал кому-то, то у этого кого-то уже есть доступ к этому чему-то. Вопрос в степени защиты.
RO
Ребят, что нужно для воспроизведения потокового аудио стрима на рельсопроекте?
СН
Источник потока и тег <audio>
u
По поводу токенов - самая классная схема которую я видел - 2 токена
Первый - длинный, используется, чтобы обновлять авторизационный токен
Второй - короткий, с временем жизни в пару минут. В нём уже хранится инфа по авторизации и он используется для того, чтоб ходить по сервисам.
Если тебе надо забанить юзера/поменять права - задержка - время жизни этого второго токена, те пара минут
Первый - длинный, используется, чтобы обновлять авторизационный токен
Второй - короткий, с временем жизни в пару минут. В нём уже хранится инфа по авторизации и он используется для того, чтоб ходить по сервисам.
Если тебе надо забанить юзера/поменять права - задержка - время жизни этого второго токена, те пара минут
u
Единственный минус - надо делать много запросов к сервису аутентифицации, который раздаёт токены. Но он маленький и быстрый, потому что занимется только этим