А кто-то, может быть, не может жить без адресной арифметики. Ну, что ему делать? Ему Go не надо, а надо C и Ассемблер, если уже такая ситуация, что на таком уровне писать надо. В общем, никаких железобетонных оснований ни для какого языка придумать нельзя

Тут все очень просто, каждый инструмент для своей задачи. Любовь - это свои домашние проекты. Есть масса экзотических языков.

И что сделает?

То, что дозволено тому человеку, для кого токен предназначался.

Уважаемые гоферы. Подскажите, пожулайста. Стоит ли юзать jwt вместо redis-sessions ?

jwt и сессии это веще принципиально разные, у них свои плюсы и минусы. сессии можно в любой момент отозвать (например закрыть все сесии на всех девайсах в случае потери телефона) jwt никак не отозвать, пока его срок годности не истечёт - он не инвалидируется. Но за-то никакого централизованного сессия-хранилища, всё stateless

То, что дозволено тому человеку, для кого токен предназначался.

Как он jwt из tls потока выделит, для начала?

А кто-то, может быть, не может жить без адресной арифметики. Ну, что ему делать? Ему Go не надо, а надо C и Ассемблер, если уже такая ситуация, что на таком уровне писать надо. В общем, никаких железобетонных оснований ни для какого языка придумать нельзя

Хотя тут я не совсем прав. Можно на Ассеблере вместе с Go. Просто прикол в том, что некоторые просто не умеют писать нормально, не считая адреса памяти в уме. :) И не могут жить без того, чтобы эту всю бухгалтерию дебажить потом ночи напролет :)

jwt и сессии это веще принципиально разные, у них свои плюсы и минусы. сессии можно в любой момент отозвать (например закрыть все сесии на всех девайсах в случае потери телефона) jwt никак не отозвать, пока его срок годности не истечёт - он не инвалидируется. Но за-то никакого централизованного сессия-хранилища, всё stateless

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

Как он jwt из tls потока выделит, для начала?

Не знаю, читал где-то, что крали.

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

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

Ну что за чушь-то

Не знаю, читал где-то, что крали.

Тогда не надо трендеть, пожалуйста

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

Есть что почитать на эту тему?

Тогда не надо трендеть, пожалуйста

сейчас попробую найти где видел. Но можно же и без https

Уважаемые гоферы. Подскажите, пожулайста. Стоит ли юзать jwt вместо redis-sessions ?

У вас уже есть этот функционал или с нуля пишете и выбираете что взять?

А действительно jwt на слуху в микросерверах. Вот тоже начал учить.

сейчас попробую найти где видел. Но можно же и без https

Тогда имя-пароль проще красть, а не jwt

Ну что за чушь-то

пришёл домой, осознал что потерял телефончик... открываешь настройки безопасности аккаунта и закрываешь все сессии. Данные в безопасности. с JWT у вора подобравшего телефон есть время получить данные в течении пока JWT валиден. Для инвалидации JWT'а нужно пилить blacklisting и per-request blacklist checking, в таком случае проще сессии реализовать...

Украдут что?!

Честь.

У вас уже есть этот функционал или с нуля пишете и выбираете что взять?

Уже есть redis-sessions. Но пришла мысль попробовать нечто другое. Пока что в раздумьях.

Уже есть redis-sessions. Но пришла мысль попробовать нечто другое. Пока что в раздумьях.

Если всем устраивает - не трогайте. Бэклог что ли пустой?

пришёл домой, осознал что потерял телефончик... открываешь настройки безопасности аккаунта и закрываешь все сессии. Данные в безопасности. с JWT у вора подобравшего телефон есть время получить данные в течении пока JWT валиден. Для инвалидации JWT'а нужно пилить blacklisting и per-request blacklist checking, в таком случае проще сессии реализовать...

Чушь. Или телефон запаролен, или в нем не jwt хранятся, а имена-пароли

Пробовать что-то, имхо, надо если текущая реализация чем-то не устраивает

Чушь. Или телефон запаролен, или в нем не jwt хранятся, а имена-пароли

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

сессии конечно повышают нагрузку на сервер в случае центрального хранилища сессий и HTTP(S) но если например коммуницировать по WebSocket'ам то аутентифицировать каждый запрос клиента уже не нужно, единственное обращение к хранилищу сесий осуществляется во время логина, а дальше запросы с сокета ассоциируются с определённой сессией что значительно снижает нагрузку на сервер

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

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

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

А за сессией можно лезть не в базу, а в memcached, например

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

1. JWT'ы частично теряют основной смысл (снижения нагрузки на сервер) когда ты добавляешь на каждый запрос jwt blacklist. Да, тебе не придётся каждый раз всю сессию читать из хранилища, ты её прочитаешь из токена, но пингануть blacklist базу таки всё-равно придётся 2. для новичка (каким автор вопроса и являлся) это вполне серьёзная проблема, легче просто сессии юзать чем внивать в криптографию, приватные ключи, инвалидацию с blacklist'ингом и т.д.. куда ты JWT запихаешь, будь то печеньки, файл, local storage и т.д. - не важно. Суть в инвалидации. Украсть можно и session key, но от него пользы не будет если сессию отозвали на сервере.

1. не нужно 2. 21-й век на дворе, новички должны уметь в криптографию. иначе они не новички, а школота проблема иналидации JWT сильно раздута, на практике это последняя из проблем безопасности

1. не нужно 2. 21-й век на дворе, новички должны уметь в криптографию. иначе они не новички, а школота проблема иналидации JWT сильно раздута, на практике это последняя из проблем безопасности

1. ну тогда у тебя потенциальная дырка в безопасности ? 2. обязательность знания криптографии - не делает криптографию проще в когнитивном плане.

была бы дыра, если бы не перекрывалась дырой по-больше каждый раз

Если всем устраивает - не трогайте. Бэклог что ли пустой?

Сохраню цитату на память

1. не нужно 2. 21-й век на дворе, новички должны уметь в криптографию. иначе они не новички, а школота проблема иналидации JWT сильно раздута, на практике это последняя из проблем безопасности

Спасибо, обласкали. Кинте тогда, что можно школоте почитать, очень уж хочу в новички переквалифицироваться

Спасибо, обласкали. Кинте тогда, что можно школоте почитать, очень уж хочу в новички переквалифицироваться

Если метишь в криптографы, то нужно знать вышмат

Вообщем в моих экспериментах с graphql победил gqlgen. Из минусов только отсутствие поддержки модулей

Вообщем в моих экспериментах с graphql победил gqlgen. Из минусов только отсутствие поддержки модулей

Он из протобуфки же генрит, если не ошибаюсь?

Если метишь в криптографы, то нужно знать вышмат

Учу потихоньку. В процессе.

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

Он из протобуфки же генрит, если не ошибаюсь?

Нет, из graphql схемы

Если всем устраивает - не трогайте. Бэклог что ли пустой?

вообще, конечно, я давно думаю, где бы взять честный таск-трекер 1. приоритетов у задач три: "прямо сегодня", "завтра" и "никогда" 2. "никогда" можно добавлять без ограничений 3. при добавлении "прямо сегодня" и "завтра" менеджер обязан оценить задачу в часах и назначить исполнителя. если у исполнителя уже больше N часов соответствующего приоритета - задача не ставится вот было бы отрезвление большинству PMов...

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

Там умножил, здесь xor, перевернул

Там умножил, здесь xor, перевернул

Там фейстель, тут square

Нет, из graphql схемы

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

Там фейстель, тут square

Короч, нужно байты туда-сюда гонять

вообще, конечно, я давно думаю, где бы взять честный таск-трекер 1. приоритетов у задач три: "прямо сегодня", "завтра" и "никогда" 2. "никогда" можно добавлять без ограничений 3. при добавлении "прямо сегодня" и "завтра" менеджер обязан оценить задачу в часах и назначить исполнителя. если у исполнителя уже больше N часов соответствующего приоритета - задача не ставится вот было бы отрезвление большинству PMов...

Ещё б ПМ знал, сколько это займет. Обычно никто, кроме твоей команды не знает

ПМ - часть команды

но, к сожалению, даже планинг-покер не дает никаких гарантий точной оценки

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

да вроде там параллельно всё щас

ну по крайней мерере то что я вижу в сгенерированном коде

но если позволить ПМ ставить задачи бесконтрольно - воспитательный эффект пропадет

вообще, конечно, я давно думаю, где бы взять честный таск-трекер 1. приоритетов у задач три: "прямо сегодня", "завтра" и "никогда" 2. "никогда" можно добавлять без ограничений 3. при добавлении "прямо сегодня" и "завтра" менеджер обязан оценить задачу в часах и назначить исполнителя. если у исполнителя уже больше N часов соответствующего приоритета - задача не ставится вот было бы отрезвление большинству PMов...

Первый таск - добавить приоритет "вчера", без оценки часов и всяких ограничений. Времени - один час.

да вроде там параллельно всё щас

Оч интересно

Посмотрю

ещё там даталоадер есть нормальный

Учу потихоньку. В процессе.

Советую книжку "Криптография. От папируса до компьютера"

Советую книжку "Криптография. От папируса до компьютера"

Даёт познания в крипте без особых углублений

Вообщем в моих экспериментах с graphql победил gqlgen. Из минусов только отсутствие поддержки модулей

codegen?

codegen?

это генератор ко "второй" либе

Советую книжку "Криптография. От папируса до компьютера"

Во. Так гораздо лучше

для понимания

Во. Так гораздо лучше

Книга может показаться устаревшей, но на самом деле криптография за последние 20 лет не особо менялась

До 90 годов была для избранных - военные, спецслужбы и т.п.

codegen?

https://github.com/99designs/gqlgen

code generation, yak... ?

code generation, yak... ?

ну ты можешь ручками писать) просто зачем?

@onokonem https://github.com/romshark/Go-2-Proposal---Immutability готовлю к публикации на днях. Глянь если интересно

Книга может показаться устаревшей, но на самом деле криптография за последние 20 лет не особо менялась

А почему её так важно знать? На столько, что это стоит таких громких высказываний про школоту?

ERROR: S client not available

А почему её так важно знать? На столько, что это стоит таких громких высказываний про школоту?

Достаточно знать базовых понятий

Хотя бы то, что на данный момент лишь один вид шифрования имеет 100% надежность, остальные просто очень долго брутфорсятся на очень быстром и специфическом железе

code generation, yak... ?

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

Хотя бы то, что на данный момент лишь один вид шифрования имеет 100% надежность, остальные просто очень долго брутфорсятся на очень быстром и специфическом железе

И какой вид шифрования имеет 100% надежность?)

Хотя бы то, что на данный момент лишь один вид шифрования имеет 100% надежность, остальные просто очень долго брутфорсятся на очень быстром и специфическом железе

Одного достаточно

И какой вид шифрования имеет 100% надежность?)

документы в сейфе с грифом Сов.Секретно, не вскрывать до "часа Х"

И какой вид шифрования имеет 100% надежность?)

Шифр Вернама

Спасибо, не слышал

Шифр Вернама

в смысле. там нельзя перебирать пароли?

И какой вид шифрования имеет 100% надежность?)

100% невозможно в природе. Но если пароль надёжный то удачи брутфорсить AES512...

в смысле. там нельзя перебирать пароли?

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

100% невозможно в природе. Но если пароль надёжный то удачи брутфорсить AES512...

Возможно

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

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

это генератор ко "второй" либе

я вот кстати смотрю и нет, это не то. там своя отдельная либа со своим блек джеком и пасьянсом

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

Почитайте Википедию по этой теме хотя бы, пожалуйста

ну звучит как-то фантастически 100% надежность :)

в смысле. там нельзя перебирать пароли?

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

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

Ключ одноразовый

ну звучит как-то фантастически 100% надежность :)

Да, но так и есть

ну звучит как-то фантастически 100% надежность :)

емнип, это математически доказанный факт

еще раз. у нас есть зашифрованній текст. вот он в файлике. длина текста 5 букв например. Значит длина шифра 5 байтов?

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

весело будет таким ключём видосы шифровать

Привет, нужно было почитать код на питоне. Кровь из глаз. Голанг расслабляет.

100% невозможно в природе. Но если пароль надёжный то удачи брутфорсить AES512...

Удачи с брутфорсом

еще раз. у нас есть зашифрованній текст. вот он в файлике. длина текста 5 букв например. Значит длина шифра 5 байтов?

Какая длина текста в битах, такая же длина ключа в битах

Какая длина текста в битах, такая же длина ключа в битах

И где проблема с вскрытием? Или все упирается в наличие этой секретной шайтан машины на двух концах передачи данных?! :))))

у нас безумно секретное число кодируется. Длина ключа в итоге 1-2 байта. Перебором не можем?!

длина ключа всегда должна быть равна длине сообщения, которое мы шифруем

И где проблема с вскрытием? Или все упирается в наличие этой секретной шайтан машины на двух концах передачи данных?! :))))

Нет проблемы, шифр говно и легко ломается. А куча математиков - это проплаченные анб взяточники чтобы дезинформировать массы

у нас безумно секретное число кодируется. Длина ключа в итоге 1-2 байта. Перебором не можем?!

Какое сообщение ты уместишь в двух байтах?

А почему её так важно знать? На столько, что это стоит таких громких высказываний про школоту?

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

я нифига не понимаю. Есть открытый алгоритм. Есть его реализации. На входе закодированный текста в пару байтов и такой-же ключ-пароль. Там каждая операция раскодировки длится часы и перебором не выходит?