Веб-разработка *

Чтобы разобраться в HTTP Request Smuggling, надо сначала честно ответить на вопрос, который в обычной жизни может прозвучать абсурдно: а как сервер понимает, где заканчивается один HTTP-запрос и начинается следующий? Кажется, что ответ очевиден — запрос это запрос, отправил и отправил. Но эта очевидность держится ровно до тех пор, пока запрос один и сервер один. Как только их становится много, а серверов в цепочке хотя бы два, выясняется, что «границу запроса» надо где-то явно записать, и способов записать её оказывается не один, и вот в этом зазоре и живёт вся уязвимость.

У меня дома зоопарк устройств: Android, iPhone, MacBook, Windows. На каждом стоит своя читалка: когда‑то на андроиде был CoolReader (отличная штука, я им вдохновлялся), на маке — платный BookReader, на айфоне — Eboox, на винде — десктопный CoolReader

Я решил написать веб‑читалку для домашнего сервера.

Тридцать лет я собирался написать игру, а потом за десять рабочих сессий довёл до продакшена браузерную Hexnome: 3D-поле, одиночный режим, онлайн-мультиплеер и серверный журнал команд. Получилось 245 промптов и 99 коммитов в основной ветке. Ещё 30 коммитов пришлось выбросить, когда первая архитектура мультиплеера оказалась «играбельной, но ненадёжной». Рассказываю, что именно ускорил AI — и какие решения он за меня не принял.

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

Привет, Хабр!

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

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

Давайте посмотрим, что я вам подготовил.

Vue снова меняет способ обновления интерфейса: теперь на горизонте Vapor и рендеринг без Virtual DOM. Зачем очередная архитектурная перестройка и что не устраивает команду Vue в нынешнем подходе?

Чтобы ответить, проследим путь Vue от Object.defineProperty до Proxy  и зачем теперь понадобился Vapor. Это поможет лучше понимать поведение ref, reactive и computed, вникнуть в причины архитектурных изменений Vue и подготовиться к дальнейшим изменениям.

ИИ-агентам нужно ходить по настоящему вебу. Но настоящий веб враждебен к автоматизации: Playwright блокируют, headless-версия Chrome палится по отпечаткам, а стелс-плагины просто становятся частью отпечатка. Если вы когда-нибудь писали скраперы или инструменты для агентов, вы знаете, как это бывает - всё работает локально, а потом продакшен разваливается за Cloudflare-челленджем.

Несколько проектов пытались решить эту проблему со стороны браузера. Проект https://camoufox.com патчит Firefox на уровне C++, так что navigator.hardwareConcurrency, WebGL-рендереры, AudioContext, геометрия экрана и WebRTC подменяются ещё до того, как JavaScript их увидит. Браузер https://github.com/jo-inc/camofox-browser оборачивает этот движок в REST API, заточенный под агентов: снимки доступности вместо раздутого HTML, стабильные ссылки на элементы для кликов и изоляция сессий.

Остаётся только одна дыра: инструментарий вокруг этой экосистемы завязан на JavaScript/Python. Если вы живёте в Go - а весь стек Go-агентов, взорвавшийся за последние пару лет, весомый аргумент в его пользу - вам оставалось писать сырые вызовы curl.

Пакет https://github.com/yvv4git/go-juggler исправляет это. Это Go-клиент для протокола автоматизации Juggler (того самого, который патчит и расширяет Camoufox) под лицензией MIT. Он управляет Firefox/Camoufox из Go с единственной зависимостью и чистым, слоистым API.

Разворачивать бэкенды для личного использования с помощью systemd удобно, но stdout плохо интегрируется с journald, а устанавливать софт только для просмотра логов не хочется. В статье - простой пример, как можно писать логи из Java-приложения в journald так, чтобы их потом удобно просматривать

В проекте периодически перезапускались PM2-воркеры. Сами рестарты сначала и были проблемой: процесс завершался, PM2 запускал новый, какое-то время всё работало нормально, затем ситуация повторялась.

По логам было понятно, что воркеры перезапускаются после достижения установленного лимита памяти. Увеличили лимит, воркеры стали жить дольше, но перезапуски никуда не делись: процесс просто позже доходил до нового значения.

И я пошёл искать причину.

Однажды в проде контейнеры одного из сервисов начали падать по OutOfMemory. Контейнерам было выделено по 4 ГБ оперативной памяти, нагрузка была вполне обычной: десятки страниц в секунду.

Расследование показало, что проблема была в JSON-конфиге.

Схема была стандартная. В базе данных хранился JSON. При запросе приложение доставало его из базы, выполняло дополнительную обработку — заполнение вычисляемых полей, обогащение справочниками — и сохраняло результат в Redis. Подавляющее большинство пользователей запрашивало один и тот же JSON и ходило за ним в Redis.

Из-за ошибки в обработке закэшированный JSON распухал до десятков мегабайт. В кэш писались не только нужные поля, но и вложенные коллекции, история изменений, сериализованные справочники.

Казалось бы, если мы запрашиваем один и тот же JSON, размер не должен так критично влиять.

Но всё оказалось интереснее…

CSS «слушает» нас. Нет, не в буквальном смысле. Суть в том, что в CSS появляется все больше псевдоклассов, которые позволяют реагировать на события JS без необходимости писать сам JS. Формально псевдоклассы отслеживают состояния, а не события, но порой они настолько похожи на обработчики событий, что разница становится почти незаметной (хотя в контексте CSS это не так уж важно).

Все главные новости из мира Joomla за апрель, май и июнь 2026 года в одной статье. Традиционно дайджест собирает новости сообщества, релизы, расширения, интеграции, видео и статьи из мира Joomla. Прошлый выпуск доступен на Хабре.

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. 

В первой статье по этой теме https://habr.com/ru/articles/1054184/ я рассказывал про принципы декомпозиции программной системы на модули и слои программных компонентов на примере задачи разработки бэкенда корпоративных чатов, рассмотрел пример реализации модуля идентификации и аутентификации пользователей на языке программирования Go.

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

Если вы хотите украсть мои данные, то начните с этой статьи! В ней подробно рассказывается, какие правила файрволла я использую, чтобы упростить вам их обход.

Конечно, я шучу. Мне даже неизвестно, читают ли веб‑краулеры посты, чтобы узнавать такую информацию.

Но я целый год занимался борьбой с ботами в своей базе данных филантропов PatronView. Когда пишешь код при помощи ИИ‑агентов, такому никто не научит, поэтому я решил поделиться полученными знаниями.

Вот некоторые факты, о которых ниже будет рассказано подробнее:

 ● Всего за один день к моему сайту обратились 3,6 миллиона запросов китайских ботов.

 ● Cloudflare сообщает, что краулеры Anthropic выполняют примерно три тысячи операций краулинга на однго приведённого посетителя. У меня этот показатель составил 35 тысяч:1.

 ● Два дня назад я заблокировал поисковый ИИ‑краулер Amazon. Он считывал по 117 тысяч страниц в день, но не направил мне ни одного посетителя.

 ● Показатель решения моей CAPTCHA равен 0,24%. Боты даже не пытаются её решать.

 ● В конце перечислены все используемые мной правила файрволла.

Представим что у вас есть свой сайт запущенный на VPS на голом HTTP, также вы уже купили домен и связали его со своим IP-адресом. 

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

Вспомнили, что есть протокол HTTPS, который по сути обычный HTTP, но на 5 и 6 уровне работает протокол SSL/TLS, который занимается шифрованием и аутентификацией.

Дело осталось за малым, перевести сайт с HTTP на HTTPS.

Привет, Habr!

Сразу дисклеймер: эта статья не реклама магазина, не туториал «парсинг за 5 минут», и я не программист. Я переводчик и штангист-любитель, а код, который будет представлен ниже, писал вместе с нейросетью. Это история о том, как одна рекомендация из книги перевернула мои представления о спортивном питании, а лень и любопытство привели к написанию скрипта, который за пару минут сделал работу, на которую у меня раньше уходило несколько часов.

Когда достаточно одного LLM-агента, когда нужна мультиагентная система, а когда лучше вообще использовать обычный workflow? Разбираем современный стек агентных приложений: ReAct, Agent SDK, графы, durable execution, sandbox, память, протоколы, evals и безопасность — с упором на практический выбор архитектуры для production.

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

Как будто все еще только начинается. Давайте разберемся, что еще могут предложить системы защиты кроме отслеживания пользователя по отпечаткам браузера, насколько это безопасно и ресурсоемко для пользователя? Разбираем что из себя представляет поведенческий антифрод.

Возможно тема эта избитая и многократно разжёванная в том числе и на Хабре. Но тем не менее актуальная, и кому-то может оказаться полезным краткий обзор.

Исторически так сложилось, что сертификаты для подтверждения подлинности веб-сайтов при шифровании были выстроены в иерархическую структуру.

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

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

И тут весь вопрос в том, кому вы доверяете.

Описанные выше корневые сертификаты с их поддеревьями заверенных иерархий образуют своеобразный лес: от каждого корня - отдельное дерево.

Стандартно браузеры либо используют свой список доверенных корневых сертификатов, либо пользуются средствами среды, то есть операционной системы (будь то Windows, iOS или Android). Как правило этот список можно дополнить или заменить на свой собственный. Например, можно выписать свой персональный (или корпоративный) сертификат, и только его оставить в списке. Это на случай, если вы доверяете только себе самому. При этом вы сами (или ваша организация) храните в тайне его секретный ключ, которым осуществляется подпись других сертификатов. И вы лично отвечаете тогда за безопасность.