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 ...). Чем сложнее и запутанее спека, тем больше там спрятано баунти для взломщика.
тем более что там даже Windows не надо, .NET [Core] можно хостить хоть под линуксом, хоть под макОС.
Если у вас заголовок аутентификации это состояние, то остальные запросы идут без него? А если другие запросы призадумаются и пользователь выйдет пока они выполняются, то они прервутся? Нет же? Значит у вас везде "состояние".
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 году, многие старики и не знают.