У Интел было как минимум три возможности перелопатить набор инструкций — при переходе в защищеный режим (286) и при смене разрядности (32 и 64). Все равно для декодирования используется режим процессора/дескрипторы. Но с 64 я смутно помню, что Интел как раз и хотела все перелопатить, но тут подсуетилась амд выпустив быстрее набор инструкций для 64 разрядности.
Признак httpOnly говорит только о том, что эта кука недоступна из javaScript и для всех запросов она работает как обычная кука. CSRF как раз и основан на автоматической отправке кук, и для него глубоко паралельно она htpOnly или нет. Поэтому ваш refresh-token для CSRF ПОЛНОСТЬЮ аналогичен обычной куке.
В обычной ситуации считается, что access-token может быть перехвачен, но из-за его короткого действия похититель ним воспользоваться не может (не успеет). А вот своровать refresh-token сложно (в идеале вообще невозможно). А у вас вы refresh-token положили вору на блюдечке (он отдается автоматически при запросе), да ещё и разрешили воспользоваться протухшим acces-token — это просто праздник для хакера.
ЗЫ: При разработке системы безопасности есть основное правило: ЕСЛИ ВЫ НЕ ЭКСПЕРТ ПО БЕЗОПАСНОСТИ СЛЕДУЙТЕ ИНСТРУКЦИИ И НЕ ПРИДУМЫВАЙТЕ СВОЮ СИСТЕМУ, ТАК КАК В ВАШЕЙ СИСТЕМЕ С ВЕРОЯТНОСТЬЮ 100% ЕСТЬ ДЫРА. :)
Хранение refresh_token в любых куках плохая идея. А тут ещё он превратился из токена в обычную сесионую куку, которой и нужна защита от CSRF. Ну и дальнейшая идея использовать в качестве CSRF токена протухший acess-token ещё хуже.
Во всех статья про плавающую точку немного лукавят, говоря что фиксированная точка спасет мир. Это не так.
Проблема IEE 754 в том что основание системы счисления хранения числа это 2 и соответственно некоторые десятичные дроби в нем не представимы. Отсюда и возникают сразу же ошибки вычислений.
Есть стандарт IEE 754- 2008 где как раз это и починили но этот стандарт в железе не реализован (может где и есть).
ЗЫ В яве есть BigDecimal из коробки, так что говорить, что Ява вообще не умеет в десятичную арифметику это не правда. С другой стороны для него нет перекрытых арифметических операций в компиляторе, поэтому писать выражения через вызов методов сложно.
Репрессии, ГУЛАГ — это решение талантливых людей с максимальной эффективностью.
Ок, больше вопросов нет.
ЗЫ: Меня всегда поражают такие люди. Вот если бы за ним поехал в 30 годах вороток, он бы и дальше рассказывал про талантливых людей в ГУЛАГЕ?!
Наверное web3.0 это когда у вас нет ничего локального, все в облаках. И нет операционной ситемы (в некотором роде). Вот гугл уже начал эксперимент со своим ChromeOS. Да и микрософт вроде как, сказав что windows 10 будет их последней операционной системой. Сейчас ещё экспериментируют с игрушками по подписке — это самая «неокученная» область сейчас.
Я бы сказал, что всякие unique_ptr, shared_ptr, weak_ptr — это явно костыли эмулирования GC.
Вообще, все зависит от сложности доменной модели — где пойдут и костыли, а где нужно задуматься о велосипеде полнго GC.
Я прекрасно понимаю что такое devops, и я согласен что разработчик должен знать как это все собрать и запустить. Так вот монорепозиториий это упрощение CI\CD. Не нужно думать какие версии библиотек брать, откуда их брать, так как это все лежит в монорепозитории. А вот как потом брать из монорепозитория для других проектов библиотеки тут начинаются танцы с бубном. То что мне предлагали, это скопировать исходный код в другой монорепозиториий.
Подведя итог можно сказать, что монорепозитории это перекладывание ответственности devops на разработчика.
В результате это только создаёт проблемы разработчику, так как разработчик всё равно не сможет полностью заменить devops.
Я бы не советовал использовать библиотеки spring oauth, так как их разработка заморожена. Весь функционал этих библиотек переносится в spring security. Например, ResourseServer уже перенесен (возможно не полностью) в spring security.
Для нахождения очередной цифры результата не обязательно параллельно вычислять 32 возможных варианта. Вы можете по старшим битам делимого и делителя по таблице найти цифру результата, один раз умножить на нее, вычесть из текущего делимого и если промазали, прибавлять делитель для восстановления делимого.
Это классическое деление в столбик.
ЗЫ Когда я реализовывал этот алгоритм там главный ньюанс выбрасывать все лидирующие нули делимого и делителя для определения цифры результата, и благодаря этому вы можете промазать только на единцу в угадывании цифры результата.
Я не понял вашего алгоритма.
Деление никак не параллелится. На каждом шаге у вас остаток, который нужно использовать на следующем шаге. Двоичный алгоритм тормозной, никто так не делает. Результат получают вычисляя его, например, побайтно, используя таблицы.
Я не эксперт в написании парсеров, но я впервые вижу что в описании грамматики есть пробелы. Из-за этого она кажется переусложнена. Насколько я помню, лексический анализатор должен бить входной поток на лексемы проглатывая пробелы. И потом в дальнейшем обработка идёт только лексем.
Далее я не слишком вдумчиво читал, но удивило что, например, для одного и того-же символа делается попытка с помощью битовых полей закодировать его как разные токены, чего в теории парсеров я не встречал.
Вы правы, чтобы проверить подпись нужно знать кто подписал. Но все равно вам нужна отдельно база тех, кому вы доверяете. Иначе плохая организация может сгенерировать открытый ключ и валидную подпись, но так как этого сгенерировано ключа нет в вашей базе, то он фейковый.
Об этом можно почитать — инфраструктура открытых ключей PKI.
Вам нужно почитать про криптографию с открытым/закрытым ключём.
Создаём qr код с ОТКРЫТЫМ текстом и его подписью закрытым ключём. Для проверки нужен всего лишь открытый ключ, ну и открытая база открытых ключей организаций, которым вы доверяете.
В обычной ситуации считается, что access-token может быть перехвачен, но из-за его короткого действия похититель ним воспользоваться не может (не успеет). А вот своровать refresh-token сложно (в идеале вообще невозможно). А у вас вы refresh-token положили вору на блюдечке (он отдается автоматически при запросе), да ещё и разрешили воспользоваться протухшим acces-token — это просто праздник для хакера.
ЗЫ: При разработке системы безопасности есть основное правило: ЕСЛИ ВЫ НЕ ЭКСПЕРТ ПО БЕЗОПАСНОСТИ СЛЕДУЙТЕ ИНСТРУКЦИИ И НЕ ПРИДУМЫВАЙТЕ СВОЮ СИСТЕМУ, ТАК КАК В ВАШЕЙ СИСТЕМЕ С ВЕРОЯТНОСТЬЮ 100% ЕСТЬ ДЫРА. :)
Обычно jwt добавляют в авторизационный заголовок:
Authorization: Bearer [jwt]
Во всех статья про плавающую точку немного лукавят, говоря что фиксированная точка спасет мир. Это не так.
Проблема IEE 754 в том что основание системы счисления хранения числа это 2 и соответственно некоторые десятичные дроби в нем не представимы. Отсюда и возникают сразу же ошибки вычислений.
Есть стандарт IEE 754- 2008 где как раз это и починили но этот стандарт в железе не реализован (может где и есть).
ЗЫ В яве есть BigDecimal из коробки, так что говорить, что Ява вообще не умеет в десятичную арифметику это не правда. С другой стороны для него нет перекрытых арифметических операций в компиляторе, поэтому писать выражения через вызов методов сложно.
Репрессии, ГУЛАГ — это решение талантливых людей с максимальной эффективностью.
Ок, больше вопросов нет.
ЗЫ: Меня всегда поражают такие люди. Вот если бы за ним поехал в 30 годах вороток, он бы и дальше рассказывал про талантливых людей в ГУЛАГЕ?!
Вообще, все зависит от сложности доменной модели — где пойдут и костыли, а где нужно задуматься о велосипеде полнго GC.
Подведя итог можно сказать, что монорепозитории это перекладывание ответственности devops на разработчика.
В результате это только создаёт проблемы разработчику, так как разработчик всё равно не сможет полностью заменить devops.
Это классическое деление в столбик.
ЗЫ Когда я реализовывал этот алгоритм там главный ньюанс выбрасывать все лидирующие нули делимого и делителя для определения цифры результата, и благодаря этому вы можете промазать только на единцу в угадывании цифры результата.
Деление никак не параллелится. На каждом шаге у вас остаток, который нужно использовать на следующем шаге. Двоичный алгоритм тормозной, никто так не делает. Результат получают вычисляя его, например, побайтно, используя таблицы.
ссылка
Далее я не слишком вдумчиво читал, но удивило что, например, для одного и того-же символа делается попытка с помощью битовых полей закодировать его как разные токены, чего в теории парсеров я не встречал.
Вы правы, чтобы проверить подпись нужно знать кто подписал. Но все равно вам нужна отдельно база тех, кому вы доверяете. Иначе плохая организация может сгенерировать открытый ключ и валидную подпись, но так как этого сгенерировано ключа нет в вашей базе, то он фейковый.
Об этом можно почитать — инфраструктура открытых ключей PKI.
Вам нужно почитать про криптографию с открытым/закрытым ключём.
Создаём qr код с ОТКРЫТЫМ текстом и его подписью закрытым ключём. Для проверки нужен всего лишь открытый ключ, ну и открытая база открытых ключей организаций, которым вы доверяете.