Ну, единственное чем Ваш способ отличается от канонического JWT — это наличием редиса как хранилища сессий.
Это в общем нормальная ситуация, но JWT может обходиться вообще без него, что многое упрощает, перекладывая заботы о state с серверного хранилища на параметры клиентского запроса.
Что плюс, так как таким токеном можно сколько угодно серверов/сервисов аутентифицировать при необходимости.
Ну и да, из JWT можно на клиенте достать ту же инфу про полномочия учётки (claims в терминологии JWT), но вы её тоже скорее всего вместе со своим токеном передаёте при необходимости — так что тут разницы кроме более занудного следования RFC не должно быть.
Естественно клиент не знает секретного ключа. (Виноват, не сказал этого достаточно ясно.)
Он просто доверяется тому, что находится в открытых для него полях, а сервер всё равно проверяет подпись ключом, который только у него есть. И проверяет полномочия конкретного аккаунта получать/изменять запрашиваемую информацию.
CSRF-токен в классическом понимании, одноразов и пробивается по базе (не обязательно, но так почему-то любят делать).
Но в общем-то Вы правы, JWT-токен — просто несколько расширенный CSRF-токен, простоself-contained, и никакой внешней информации ему для валидации в общем случае не надо. Что делает сервер лишённым состояния — а это плюс.
Кстати, это достаточно интересная идея. Например, для таких пользователей можно заранее более жёстко какие-то другие меры отрабатывать, типа влогинивания с незнакомого компьютера.
Ну или просто после трёх-пяти попыток войти с неверным паролем не капчу показывать, а хост блокировать — тут уж как у кого фантазии хватит.
Вместо куки серверу в момент аутентификации предлагается возвращать JSON-объект, подписанный при помощи HMAC и секретного ключа сервера. В этом объекте может храниться собственно айдишник пользователя, таймстамп истечения сессии, и любая друга информация которая может быть полезна для работы с пользователем.
Дополнительные параметры могут использоваться как на клиенте (если там стоит isAdmin: true, то показывать админские элементы в интерфейсе), так и в логике на сервере при последующих запросах. При этом на сервер токен стоит передавать при помощи кастомного хедера в запросе — и тогда атаки CSRF перестают работать автоматом.
Дополнительный плюс — сервер может не хранить состояния, а просто доверять данным, которые в токене пришли (если токен не протух и валидация HMAC секретным ключом прошла, естественно). Соответственно, можно использовать внешний auth-сервер для многих проектов. Ну или шардиться по многим серверам без дополнительных усилий.
В таком случае, Server push + работа с чанками как с логически-низависимыми кусками (типа файлов-томов в некоторых архивах) действительно сможет решить Вашу задачу. Пожалуйста, перечитайте внимательнее про эту технологию: tools.ietf.org/html/draft-ietf-httpbis-http2-12#page-60
HTTP/2 enables a server to pre-emptively send (or «push») one or more
associated responses to a client in response to a single request.
This feature becomes particularly helpful when the server knows the
client will need to have those responses available in order to fully
process the response to the original request.
Предполагаю, что до какой-то степени это хотение можно удовлетворить, представляя фрагменты в виде изолированных логических сущностей, и отправляя на сервер при помощи упомянутого Server push.
При этом мне стало любопытно, для какой пользы можно было бы применить эту технику?
А ещё можно поднять на своей железке prerender.io (ну или заплатить им за сервис, кому что проще), на него простым конфигом nginx перенаправить поисковики с основного сайта — и не писать кода воообще ;).
При запросе репозитория эта строка схлопывается в packages.erlang-solutions.com/debian/dists/precise/contrib/binary-amd64/
Соответственно, чудо-обновлятор мог бы проверять существование такой же папочки, но с новым кодом дистрибутива, и если есть (что верно, наверное, в 75% случаев) — подновлять нужным образом строчку.
Там сугубо про Windows-версию идёт речь. Мы точно её обсуждаем в этом треде?
Yes, generally it is affected. It depends on the OPENSSL version used. On linux the openssl is a separate package, so you can update it with the new fix posted on the official openssl web site. But the OpenVPN Windows client is bundled with the openssl library, so you should either wait for official OpenVPN update or try to update the openssl library only.
Ну, если вы про ядро — то есть же пакеты типа `linux-generic-lts-saucy`.
А если про какие-то конкретные софты, то где-то 75% случаев лечатся ручным бекпортированием, через `apt-get source`, `apt-get build-dep` и `debuild`. (При включённом источнике `deb-src` из нужного дистра.)
Неаккуратно, конечно, и ручная работа требуется. Зато достаточно свежий софт, и запакетирован нормально за меня.
Скорее всего (если только вы не используете какой-нибудь богомерзкий Генту, да ещё и в гамаке и ластах со статической компиляцией библиотект), ваш линукс динамически линкует пакетированный OpenVPN с пакетированным же OpenSSL. Соответственно, обновление пакетов и перезагрузка (для верности, фиг его знает как оно там символы из сторонних библиотек кеширует в райнтайме) — и дело в шляпе.
Это в общем нормальная ситуация, но JWT может обходиться вообще без него, что многое упрощает, перекладывая заботы о state с серверного хранилища на параметры клиентского запроса.
Что плюс, так как таким токеном можно сколько угодно серверов/сервисов аутентифицировать при необходимости.
Ну и да, из JWT можно на клиенте достать ту же инфу про полномочия учётки (claims в терминологии JWT), но вы её тоже скорее всего вместе со своим токеном передаёте при необходимости — так что тут разницы кроме более занудного следования RFC не должно быть.
Он просто доверяется тому, что находится в открытых для него полях, а сервер всё равно проверяет подпись ключом, который только у него есть. И проверяет полномочия конкретного аккаунта получать/изменять запрашиваемую информацию.
CSRF-токен в классическом понимании, одноразов и пробивается по базе (не обязательно, но так почему-то любят делать).
Но в общем-то Вы правы, JWT-токен — просто несколько расширенный CSRF-токен, простоself-contained, и никакой внешней информации ему для валидации в общем случае не надо. Что делает сервер лишённым состояния — а это плюс.
— А кто же тогда картинки пользователю отдавать будет?
Ну или просто после трёх-пяти попыток войти с неверным паролем не капчу показывать, а хост блокировать — тут уж как у кого фантазии хватит.
Немного погуглив JWT+нужный язык можно легко найти либы для более-менее всего чего угодно, по моему опыту.
Дополнительные параметры могут использоваться как на клиенте (если там стоит isAdmin: true, то показывать админские элементы в интерфейсе), так и в логике на сервере при последующих запросах. При этом на сервер токен стоит передавать при помощи кастомного хедера в запросе — и тогда атаки CSRF перестают работать автоматом.
Дополнительный плюс — сервер может не хранить состояния, а просто доверять данным, которые в токене пришли (если токен не протух и валидация HMAC секретным ключом прошла, естественно). Соответственно, можно использовать внешний auth-сервер для многих проектов. Ну или шардиться по многим серверам без дополнительных усилий.
При этом мне стало любопытно, для какой пользы можно было бы применить эту технику?
Вывод: нефиг с планшетки писать не глядя.
Ибо забанить легко получилось в первую очередь bootstrap-ноды.
(Борьба бобра с ослом там постоянно крепчает, так что инфа легко могла устареть уже.)
На скриншотах в описании — постеры фильмов, например.
deb packages.erlang-solutions.com/debian precise contrib
При запросе репозитория эта строка схлопывается в packages.erlang-solutions.com/debian/dists/precise/contrib/binary-amd64/
Соответственно, чудо-обновлятор мог бы проверять существование такой же папочки, но с новым кодом дистрибутива, и если есть (что верно, наверное, в 75% случаев) — подновлять нужным образом строчку.
А если про какие-то конкретные софты, то где-то 75% случаев лечатся ручным бекпортированием, через `apt-get source`, `apt-get build-dep` и `debuild`. (При включённом источнике `deb-src` из нужного дистра.)
Неаккуратно, конечно, и ручная работа требуется. Зато достаточно свежий софт, и запакетирован нормально за меня.
в гамаке и ластахсо статической компиляцией библиотект), ваш линукс динамически линкует пакетированный OpenVPN с пакетированным же OpenSSL. Соответственно, обновление пакетов и перезагрузка (для верности, фиг его знает как оно там символы из сторонних библиотек кеширует в райнтайме) — и дело в шляпе.