« Rev
@kubernetes_ru   959
Fwd »


Руслан true.sorcerer
завести на центе геморой а держать в докере не торт
manefesto
Центом норм для явы, докера, оракла. А так очень специфичная вещь
Руслан true.sorcerer
прокся для мемкешей от фейсбука
Rainbow
я один раз завел... там семафоры udev утекали, просто бага docker & ядро. Круто было.
manefesto
Может
Rainbow
echo 'y' | dmsetup udevcomplete_all круто ставить на крон
Ян
прокся для мемкешей от фейсбука
нахер мемкеши. они блять мутируют. месяц понять не мог что за дичь творится в проекте. у него данных на 10 гиг, ключи путаются между собой
Руслан true.sorcerer
нахер мемкеши. они блять мутируют. месяц понять не мог что за дичь творится в проекте. у него данных на 10 гиг, ключи путаются между собой
мемкеш деревянный и шустрый это плюс, наверняка где-то был проеб, его сложно сломать если только это не плагин к мускулю
Руслан true.sorcerer
напрямую с пхп работал. заменили на редис, все стало збс
это хорошо если есть возможно переписать под редис апликуху
Руслан true.sorcerer
или аероспайк или коуч
Rainbow
couch как пересекается с redis? разные кейсы же
Ян
там был абстрагирован интерфейс для кеша, кишки чуток поправили и стал работать с редисом)
Ян
кстати. мылорушный тарантул юзает кто?
Rainbow
https://github.com/leo-yuriev/libfpta есть православная штука, для тех кого redis/мемкеш смущает.
Руслан true.sorcerer
couch как пересекается с redis? разные кейсы же
он умеет в мемкешед протокол
Rainbow
лучше jwt вместо сессий и без базы
Ян
сессии лучше в монгу
не сами сессии. хотя они тоже были в мемкеше, но в отдельном. там дополнительная инфа была, но уникальность ключей держалась на сессионных ключах
Rainbow
хайпом
Руслан true.sorcerer
лучше jwt вместо сессий и без базы
тут не в курсе, как это хранить?
Руслан true.sorcerer
чем?
надежность
Rainbow
никак
Rainbow
это подписывается на сервере и проверяется при обращении
Rainbow
нужно только иметь список отозванного если печёт
Etki
тут не в курсе, как это хранить?
никак, ты просто запихиваешь данные в грубо говоря контейнер, целостность и достоверность которого подтверждается подписью
Руслан true.sorcerer
а сами данные в чем лежат?
Etki
ну и потом шлешь это все туда-обратно
Rainbow
base64(json) обычно
Etki
в джейсоне, завернутом в base64
Руслан true.sorcerer
ин мем?
Etki
надежность
это ж сессии
Rainbow
на сервере не хранитятся никакие jwt, он только генерит по секрету
Руслан true.sorcerer
это ж сессии
нуда их нельзя терять, это вообще не торт подход
Etki
ин мем?
ты выписываешь эту штуку на сервере, а клиент потом шлет при каждом запросе. как куки, или даже на основе кук.
Etki
за счет подписи ты всегда можешь быть уверен, что выписал это дело именно ты, и по-хорошему у этой штуки есть проверка audience и ttl, чтоб совсем уж точно
Руслан true.sorcerer
ты выписываешь эту штуку на сервере, а клиент потом шлет при каждом запросе. как куки, или даже на основе кук.
это типа генерации паблик кей? а сервер просто проверят? плюс еще гдето хранит?
Etki
но сесси туда пихать конечно такое дело, потому что в какой-то момент окажется, что хедеры занимают 2/3 запроса
Руслан true.sorcerer
оверхед по идее должен быть неслабый
Etki
это типа генерации паблик кей? а сервер просто проверят? плюс еще гдето хранит?
обычно просто хэш, но да, там есть куча криптографических алгоритмов
Руслан true.sorcerer
никогда не встречал, нужно будет курнуть
Etki
https://jwt.io/
Руслан true.sorcerer
но пока логики и профита не понял)
Etki
но пока логики и профита не понял)
с публичными ключами ты действительно можешь удостовериться, что эту jwt выписал конкретный источник
Руслан true.sorcerer
ну это же какойто аналог по котрому мы определяем кастомера?
Rainbow
Да, там внутри любой json с данными кастомера
Etki
С хэшем тебе придется знать его собственный секрет, а тут вообще все клево. И пользователь сам тебе сообщает свои роли, а ты подтверждаешь их достоверность с помощью публичного ключа. Сам юзер, пока не утек приватный ключ, не может сам себе их выписать.
Руслан true.sorcerer
а сложности миграции с обычных сессий?
Rainbow
Проще намного
Руслан true.sorcerer
нагрузки выростают правильно?
Etki
а сложности миграции с обычных сессий?
Это все-таки не совсем сессии, это способ передачи клеймов и прочей меты о юзере. Но если сильно хочется, то просто на каждом запросе подтверждаешь токен и делаешь бейз64 декод + джейсон декод
Rainbow
Кроме того, что жрет cpu больше на криптографию, но это не сильно важно.
Руслан true.sorcerer
как минимум проц, экономим на оперативке и хранилище
Etki
ну если консюмер и продюсер один и тот же, то затраты на хэш должны быть не такими уж сильными
Руслан true.sorcerer
чем больше новых юзеров тем выше нагрузка получается
Rainbow
нет
Etki
чем больше новых юзеров тем выше нагрузка получается
ну как бы с базой данных то же самое будет, только приплюсуй сюда нетворк и диск
Rainbow
ну и да и нет. на обычных сессиях куча пользователей - куча места под сессии.
Rainbow
тут можно хоть отдельным сервом генерить/чекать токены
Etki
Сейчас macaroons хипово
спасибо, читаю
Руслан true.sorcerer
тут можно хоть отдельным сервом генерить/чекать токены
по идее легко горизонтально масштабируется
Rainbow
да. Главное secret не потерять.
Rainbow
2 сервера с одним секретом дают валидные токены
Руслан true.sorcerer
ну это понятно) мы чтото с темы съехали
Etki
если ttl с самого начала делать - ну будет просто перелогин для каждого пользователя
Руслан true.sorcerer
и это все на джаве я правильно понял?
Etki
на любом языке
Etki
де-факто это просто джейсон-пейлоад с подписью, которую при желании ты можешь даже не верифицировать
« Rev
@kubernetes_ru   959
Fwd »