это типа генерации паблик кей? а сервер просто проверят? плюс еще гдето хранит?

обычно просто хэш, но да, там есть куча криптографических алгоритмов

никогда не встречал, нужно будет курнуть

https://jwt.io/

но пока логики и профита не понял)

но пока логики и профита не понял)

Не нужны сессии

но пока логики и профита не понял)

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

ну это же какойто аналог по котрому мы определяем кастомера?

Да, там внутри любой json с данными кастомера

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

на сервере не хранитятся никакие jwt, он только генерит по секрету

Сейчас macaroons хипово

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

так вроде понятно

а сложности миграции с обычных сессий?

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

Угу, селект на роли делать не нужно. Хоть все права записать в токен.

Проще намного

нагрузки выростают правильно?

а сложности миграции с обычных сессий?

Это все-таки не совсем сессии, это способ передачи клеймов и прочей меты о юзере. Но если сильно хочется, то просто на каждом запросе подтверждаешь токен и делаешь бейз64 декод + джейсон декод

Кроме того, что жрет cpu больше на криптографию, но это не сильно важно.

как минимум проц, экономим на оперативке и хранилище

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

чем больше новых юзеров тем выше нагрузка получается

нет

чем больше новых юзеров тем выше нагрузка получается

ну как бы с базой данных то же самое будет, только приплюсуй сюда нетворк и диск

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

тут можно хоть отдельным сервом генерить/чекать токены

Сейчас macaroons хипово

спасибо, читаю

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

это факт, плюс время хранения

тут можно хоть отдельным сервом генерить/чекать токены

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

да. Главное secret не потерять.

2 сервера с одним секретом дают валидные токены

ну это понятно) мы чтото с темы съехали

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

и это все на джаве я правильно понял?

на любом языке

де-факто это просто джейсон-пейлоад с подписью, которую при желании ты можешь даже не верифицировать

хм, спасибо за инфу покурю

а стоп, недостатки?

больше передавать по сети + пользователь видит все, что ему передано

легче всрать, нужно поддерживать инфраструктуру для refresh token

а как происходит отзыв?

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

по ttl, если нужно срочно - надо держать аналог CRL на сервере

Обычно просто есть refresh token, который можно обменять на новый jwt, поэтому для пользователя это все вообще незаметно.

в токене можно писать {"is_admin": true} если поменять пользователю права, то он увидит изменения только после релогина, потому что в коде if (token.is_admin) { } и все.

Обычно просто есть refresh token, который можно обменять на новый jwt, поэтому для пользователя это все вообще незаметно.

просто запрос "дай мне новый токен"

просто запрос "дай мне новый токен"

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

нет

я всегда в токене храню user_id. В чем проблема выдать по запросу?

пока жив текущий

он может уже быть не жив

а, в том, что он подохнет.

ок

а сам экспаринг как происходит? просто отзывает отдельно или есть какойто ттл?

есть ttl

если нужно раньше, то blacklist

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

если нужно раньше, то blacklist

и можно не руками по какойто логике?

вся логика кроме ttl руками, как нужно в конкретном случае

ладно нужно разбираться и это не в пятницу вечером)

раньше все юзали config файла, а сейчас ENV примерно так же с сессиями и jwt

и можно не руками по какойто логике?

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

а стоп, недостатки?

ну еще можно украсть refresh token из jwt за счет какого-нибудь xss, если только он не передается как httpOnly кука

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

очень печальная история будет)

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

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

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

а что делать в ситуации когда сессий гигов на 600? ))

засовывать в линейно масштабируемое хранилище (из самых ярких примеров кассандра / scylladb , dynamodb)

а что делать в ситуации когда сессий гигов на 600? ))

Ну можно плавно переезжать на новый ключ :) сначала все у кого хеш меньше X, потом 2x, потом 3x :)

чтото выглядит извращенно)

Ну можно плавно переезжать на новый ключ :) сначала все у кого хеш меньше X, потом 2x, потом 3x :)

выдавать на авторизации новые jwt. Через пару недель дропнуть все сессии и все.

Горячие плавно переедут, а у старых и так сессии сдохнут.

чтото выглядит извращенно)

С корневыми сертификатами похожая (но немного другая) история

да чтото есть похожее

Я узнаю его из тысячи ? А вообще реально боль. Есть нормальные рецепты на vim?

Есть расширение для VS Code, которое подсвечивает табы разными цветами

https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow

Удобно не только для YAML, но и для кода на питоне и вообще

Я узнаю его из тысячи ? А вообще реально боль. Есть нормальные рецепты на vim?

https://github.com/Yggdroot/indentLine

https://github.com/Yggdroot/indentLine

спасибо, это посимпатичней

как то антиспам не сработал )

Похоже на ажур)

Похоже на ажур)

ахаха

Кто-нибудь rook.io в проде использует?

Кто-нибудь rook.io в проде использует?

Сто раз обсуждали Берите обычный цеф

Сто раз обсуждали Берите обычный цеф

Почему? Возможно ли развернуть ceph в kubernetes и его же использовать в качестве хранилища?

Почему? Возможно ли развернуть ceph в kubernetes и его же использовать в качестве хранилища?

Можно развернуть цеф без кубернетеса и использовать его в нём. У меня, например, на тестовом образце rook просто потерял все osd после перезагрузки

Кто-нибудь rook.io в проде использует?

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

Можно развернуть цеф без кубернетеса и использовать его в нём. У меня, например, на тестовом образце rook просто потерял все osd после перезагрузки

о, у нас тоже. правда пять лет назад, но запомнилось

ребят, что лучше выбрать для кручения нетворка в дев среде с сингл-мастером и мульти-нодами?

калико?

калико?

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