WebSockets делают ваши подписки GraphQL сохраняющими состояние
Если у вас заголовок аутентификации это состояние, то остальные запросы идут без него? А если другие запросы призадумаются и пользователь выйдет пока они выполняются, то они прервутся? Нет же? Значит у вас везде "состояние".
WS в качестве потока событий вообще никак не отличается от SSE. Одни и те же преимущества, те же проблемы с аутентификацией (нет возможности задать заголовки).
Но у WS есть per-message-deflate, а у SSE из коробки ничего.
WebSockets заставляют браузер откатиться к HTTP/1.1
RFC 8441 уже 6 лет как в node.js, да и в отстальных серверах оно есть
WebSockets вызывают проблемы безопасности, раскрывая токены аутентификации клиенту
Дак не раскрывайте. Кукисы, одноразовые токены итд.
WebSockets позволяют двунаправленную связь
Плюс же, а не минус. Выработайте протокол взаимодействия по вашему каналу, и закрывайте соеднинение при его нарушении.
А знаете что лучше и дешевле SMS? Email. А что ещё проще в реализации и маштабируется на 1кк пользователей? HOTP и TOTP. А что безопаснее всего? Хардварные токены.
Нет, это вы заблуждаетесь, фраза "не более одного раза " в документации CLR и у Рихтера должна была вам намекнуть, что - 0 раз это всё еще "не более одного раза". Если бы там была гарантия "ровно один раз", толгда бы и можно было сказать что поле "будет" инициировано. А так любое поле до может сделать лок и зависнуть в нем - опа и 0 раз, Mono, к примеру повесит секунд 30, а потом скажет "похуй" и оставит поле в null а тред инициализации зависшим. Второй кейс это Exception в во время инициализации этого или другого поля.
Привыкайте получать сопроводительное письма от ChatGPT т.к. ни тимлиду ни кандидату они никуда не упёрлись, только рекрутер хочет почитать какой у него поток мотивированных кандидатов.
На самом деле ручная проверка токена в коде ( signature, exp, iss & etc ) даст мнимое улучшение производительности по сравнению с отправкой в keycloak, который сделает это сам.
Это очень смело утверждать что посчитать SHA-1/SHA-256 хеш либо RSA подпись == по перфомансу с открытием соединения, отправкой данных, подсчетом того-же SHA хеша и парсингом ответа.
Я бы сказал что разница в порядок, а может и в порядки.
Отзыв JWT токенов скорее это неправильный дизайн чем кейс.
Генерация токена настолько дорогая, насколько и проверка - посчитать хеш и чуток JSON сериализации. Я реализовывал всё из списка, там ничего "тяжелого" по перформансу нет.
он каждый запрос к /data делает допольнительный запрос к keycloak? не кажется это расточительным, когда JWT используют именно для того что бы этого не делать.
Я понимаю, что это перевод. Но вопросики всегда могут быть к тому кто перевел, ведь он выбирает качество материала.
А чему радоваться, он вернулся с лозунгом - вы недожимаете с инклюзивностью, я вам сейчас покажу. Это он сказал словами через рот в интервью. И протащил Копалди через грязь в рождественском эпизоде.
В статьях про WAF не пишут, что это для legacy и Web-приложений класса "Решето" (привет. Confluence). Даже тут написано про микросервисы и современную цифровизацию.
Непонятно, каким образом вы смогли убедиться, что вам будут приходить только "запросы строго по спецификации"
Приходить будут любые, обрабатываться только те которые есть в спецификации т.к. для других нет кода :)
что у вас нет OWASP Top 10
В имозрительном примере их просто не сделали. В реальных проектах они поправлены, и проверены командой QA которые специализируются на это, не рокет саинс.
что у вас нет и никогда не появится уязвимостей в серверной ОС, в фреймворке, в HAProxy и т.п.
Они есть, будут итд. Но пока открыт только 80 порт уязвимость может быть в сетевом стеке ОС (шанс 0%, иначе всё уже было взломано по кругу), в HAProxy (шанс поменьше, но аналогично, тысячи сайтов уже были бы взломаны) и мой фреймворк и мой код. Тут я могу проверить и быть увереным в результате.
А вот еще один продукт в цепочке типа WAF это штука которая как миннимум бесполезна, а скорее сама содержит ошибки и уязвимости. Проверить ее нельзя. Чет исходников для предложенной системы не нашел.
Не получил ответ на вопрос "зачем вообще это все нужно". Вот есть у меня web-приложение на GO, или даже много приложений на GO в кубере, балансировщик на HAProxy, наружу торчит 80 порт, запросы строго по спецификации. SQL-injection и другие OWASP TOP-10 отсутствуют.
Для чего мне могут понадобится обычный firewall и WAF?
Разработчик который использует YAML для передачи данных заслуживает быть взломанным.
Более неоднозначного для реализации текстового формата еще надо поискать. Одинаковых реализаций нет, все имеют хоть какие-то отклонения от стандарта.
Даже, JSONа, спека которого умещается на салфетке, корректных реализаций дай бог одна на ЯП. Одни игнорируют лишние/отсутствующие запятые, многие поддерживают комментарии итд.
В таких расхождениях реализации стандартов и живут многие уязвимости (HTTP Request Smuggling, URL Parsing Confusion ...). Чем сложнее и запутанее спека, тем больше там спрятано баунти для взломщика.
Небольшая задача или несколько задач, которые помогают проверить хардскилы соискателя. Обычно на выполнение задания даётся несколько дней. Тестовое задание дают не во всех компаниях.
Пожалуй нет. Если только не платится тестовая оплата.
Если у вас заголовок аутентификации это состояние, то остальные запросы идут без него? А если другие запросы призадумаются и пользователь выйдет пока они выполняются, то они прервутся? Нет же? Значит у вас везде "состояние".
WS в качестве потока событий вообще никак не отличается от SSE. Одни и те же преимущества, те же проблемы с аутентификацией (нет возможности задать заголовки).
Но у WS есть per-message-deflate, а у SSE из коробки ничего.
RFC 8441 уже 6 лет как в node.js, да и в отстальных серверах оно есть
Дак не раскрывайте. Кукисы, одноразовые токены итд.
Плюс же, а не минус. Выработайте протокол взаимодействия по вашему каналу, и закрывайте соеднинение при его нарушении.
Дак YAML человекопонятен, проблема писать на нем.
А знаете что лучше и дешевле SMS? Email. А что ещё проще в реализации и маштабируется на 1кк пользователей? HOTP и TOTP. А что безопаснее всего? Хардварные токены.
А у вас тут оголтелая реклама.
Про это написано.
А вот про это нет :) Например можно было написать про:
Как обойтись без синхронизации в многопоточном приложении
Copy-on-write стуктуры данных
Mergeable Replicated Data Types и подобные попытки
Когда можно вообще забить на синхронизацию
Обзор возможных Concurrency control механизмов
Как гарантировать корректность многопоточного приложения
Какие варианты есть кроме блокировок
btw. Судя по обилию воды и вежливым оборотам, статья обработана ИИ по самое небалуй, не пора ли хабре заставлять делать дисклеймер об этом.
Нет, это вы заблуждаетесь, фраза "не более одного раза " в документации CLR и у Рихтера должна была вам намекнуть, что - 0 раз это всё еще "не более одного раза". Если бы там была гарантия "ровно один раз", толгда бы и можно было сказать что поле "будет" инициировано. А так любое поле до может сделать лок и зависнуть в нем - опа и 0 раз, Mono, к примеру повесит секунд 30, а потом скажет "похуй" и оставит поле в null а тред инициализации зависшим.
Второй кейс это Exception в во время инициализации этого или другого поля.
Многое пропустили если вообще не знакомы с контейнерами. Остальное из списка наносное, завтра у аналогичных инструментов будут другие названия.
И не гарантированная. Вот программист удивится когда там будет null.
Привыкайте получать сопроводительное письма от ChatGPT т.к. ни тимлиду ни кандидату они никуда не упёрлись, только рекрутер хочет почитать какой у него поток мотивированных кандидатов.
Это очень смело утверждать что посчитать SHA-1/SHA-256 хеш либо RSA подпись == по перфомансу с открытием соединения, отправкой данных, подсчетом того-же SHA хеша и парсингом ответа.
Я бы сказал что разница в порядок, а может и в порядки.
Отзыв JWT токенов скорее это неправильный дизайн чем кейс.
Генерация токена настолько дорогая, насколько и проверка - посчитать хеш и чуток JSON сериализации. Я реализовывал всё из списка, там ничего "тяжелого" по перформансу нет.
он каждый запрос к /data делает допольнительный запрос к keycloak? не кажется это расточительным, когда JWT используют именно для того что бы этого не делать.
Я понимаю, что это перевод. Но вопросики всегда могут быть к тому кто перевел, ведь он выбирает качество материала.
А чему радоваться, он вернулся с лозунгом - вы недожимаете с инклюзивностью, я вам сейчас покажу. Это он сказал словами через рот в интервью. И протащил Копалди через грязь в рождественском эпизоде.
А у вас в примере специально не проверяется заголовок и подпись JWT токена или это ошибка?
В статьях про WAF не пишут, что это для legacy и Web-приложений класса "Решето" (привет. Confluence). Даже тут написано про микросервисы и современную цифровизацию.
Приходить будут любые, обрабатываться только те которые есть в спецификации т.к. для других нет кода :)
В имозрительном примере их просто не сделали. В реальных проектах они поправлены, и проверены командой QA которые специализируются на это, не рокет саинс.
Они есть, будут итд. Но пока открыт только 80 порт уязвимость может быть в сетевом стеке ОС (шанс 0%, иначе всё уже было взломано по кругу), в HAProxy (шанс поменьше, но аналогично, тысячи сайтов уже были бы взломаны) и мой фреймворк и мой код. Тут я могу проверить и быть увереным в результате.
А вот еще один продукт в цепочке типа WAF это штука которая как миннимум бесполезна, а скорее сама содержит ошибки и уязвимости. Проверить ее нельзя. Чет исходников для предложенной системы не нашел.
Не получил ответ на вопрос "зачем вообще это все нужно".
Вот есть у меня web-приложение на GO, или даже много приложений на GO в кубере, балансировщик на HAProxy, наружу торчит 80 порт, запросы строго по спецификации. SQL-injection и другие OWASP TOP-10 отсутствуют.
Для чего мне могут понадобится обычный firewall и WAF?
Разработчик который использует YAML для передачи данных заслуживает быть взломанным.
Более неоднозначного для реализации текстового формата еще надо поискать. Одинаковых реализаций нет, все имеют хоть какие-то отклонения от стандарта.
Даже, JSONа, спека которого умещается на салфетке, корректных реализаций дай бог одна на ЯП. Одни игнорируют лишние/отсутствующие запятые, многие поддерживают комментарии итд.
В таких расхождениях реализации стандартов и живут многие уязвимости (HTTP Request Smuggling, URL Parsing Confusion ...). Чем сложнее и запутанее спека, тем больше там спрятано баунти для взломщика.
Дженерики не всегда сделаны через type erasure.
На скринах XCOM 2, но и в первом "новом" XCOM: Enemy Unknown аналогичная система абилок.
Так то оператор возведения в степень ** появился в JS только в 2016 году, многие старики и не знают.
Пожалуй нет. Если только не платится тестовая оплата.