Главное
Теперь вы можете создавать, отправлять и повторять запросы со своим API key прямо в панели управления. Новый playground поддерживает все три продукта и сохраняет cookies, пресеты и историю между запусками. Вместе с ним вышли два исправления надежности: unblocker: true незаметно деградировал в течение нескольких недель (теперь он снова работает end-to-end), а Browser теперь надежно захватывает cookie cf_clearance пассивного челленджа Cloudflare.
Что нового
Playground в панели управления
/dashboard/#playground превратился в полноценный рабочий инструмент. Три вкладки продуктов (Single, Proxy Finder, Browser), строка URL, headers, body, а также все флаги для каждого продукта, точно соответствующие их схемам. Отправьте запрос и смотрите на рендер ответа в режимах JSON, HTML или text. Ищите по панелям ответа с помощью Ctrl/Cmd+K. Разворачивайте ответ на весь экран, когда нужно разобрать большой объем HTML.
Несколько возможностей, появившихся благодаря тому, что мы делали инструмент под свои рабочие задачи:
- Полученные cookies сохраняются в jar с привязкой к хосту. Следующий запрос к тому же хосту прикрепляет их автоматически, при этом вы можете просмотреть, изменить или удалить любой cookie перед отправкой.
- Панель рабочих proxy собирает все proxy id из успешного запуска Proxy Finder, позволяя нажать "использовать" и применить этот proxy в запросе Single или Browser без повторного ввода.
- Сохранение запросов в виде пресетов. Повторный запуск любого из последних 20 запросов через диалог истории.
- Генератор cURL показывает точную команду (включая
x-api-key), которую можно запустить в терминале для выполнения того же запроса.
Playground подписывает короткоживущий внутренний token, поэтому ваш ключ в открытом виде никогда не покидает панель управления. Квоты, метрики и last_used_at учитываются для выбранного ключа точно так же, как если бы запрос был отправлен из вашего собственного кода.
unblocker: true снова работает end-to-end
Мы обнаружили проблему сборки, которая последние несколько недель незаметно ухудшала запросы Single и Proxy Finder с unblocker: true. Сборка ушла в релиз без фактического подключения профиля браузера, поэтому запросы, которые должны были нести сигнатуру браузера, получали generic сигнатуру. Сайты, которые должны были пропускать запросы, блокировали нас.
Исправление развернуто. Мы проверили работу end-to-end на одиннадцати реальных таргетах, включая три цели с проверками, для которых раньше требовался Browser. Single проходит их самостоятельно. Цепочка Proxy Finder + Browser + Single (найти proxy, получить cf_clearance cookie через Browser, отправить запрос страницы через Single с этим cookie и тем же proxy) возвращает полный HTML за один round trip.
Это наша ошибка. unblocker: true работал в день релиза, но тихо сломался во время плановой пересборки. Если за последние недели вы отправляли запрос с unblocker: true к защищенному сайту и получили 403 вместо 200, причина была в этом. Попробуйте снова.
Browser обрабатывает пассивный JavaScript-челлендж Cloudflare
У Cloudflare есть два режима проверок. Активный режим (HTTP 403 плюс промежуточная страница) мы уже обрабатывали. Пассивный режим хитрее: страница сразу возвращает 200, но Cloudflare внедряет асинхронный JavaScript-зонд, который собирает цифровой отпечаток клиента и только затем выдает cookie cf_clearance. До этого исправления Browser завершал обработку ответа до того, как зонд успевал отработать, поэтому cookie проверки так и не попадал в хранилище.
Теперь Browser явно слушает событие Set-Cookie и ожидает cf_clearance, если видит маркер пассивной проверки в теле ответа. Никакого поллинга, фиксированных задержек или лишнего ожидания для сайтов без Cloudflare. Двенадцать реальных доменов в тестовом наборе, три из которых используют пассивный путь, теперь стабильно возвращают cookie проверки.
Закрыта уязвимость SSRF на границе API
Действующий API-ключ pk_live_... не дает права доступа к нашей внутренней сети. Теперь API отклоняет любую цель, если ее имя хоста или результат DNS-резолвинга попадает в зарезервированные диапазоны RFC 5735, 6598 или зарезервированные блоки IPv6. Такая же проверка выполняется на каждом бэкенд-сервисе в качестве второго рубежа защиты.
Внешне ничего не изменилось. Мы просто блокируем целый класс попыток сканирования внутренней сети еще до завершения TCP-рукопожатия.
Уникальные превью для блога в соцсетях и исправление пагинации
Каждая публикация в блоге теперь генерирует собственное изображение Open Graph с заголовком и кратким описанием статьи на фирменной карточке. Вставьте ссылку foura.ai/blog/... в Discord, LinkedIn, Slack или Twitter, и вы увидите превью конкретного поста вместо стандартной заглушки.
Пагинация на главной странице блога работала некорректно. Кнопка «Older» возвращала на страницу 1. Мы перевели пагинацию на URL на основе путей (/blog/page/N/), добавили нумерованную навигацию с адаптивным окном и проставили корректные теги rel=prev/next для страниц списков. Старые URL вида ?page=N отдают 301 редирект на новый формат, поэтому проиндексированные ранее страницы не потеряются.
Под капотом
Наш MCP-сервер запущен по адресу mcp.foura.ai для любых LLM-инструментов, поддерживающих Model Context Protocol. Аутентификация работает через тот же Bearer token pk_live_..., что и для REST API. Сервер предоставляет три продукта в виде инструментов (Single, Proxy Finder, Browser) и набор готовых промптов. Если вы подключаете FourA к Claude Code или любому агенту с поддержкой MCP, локальный мост больше не нужен.
Если вы откладывали знакомство с панелью управления, потому что прошлая песочница казалась сырой, загляните туда на этой неделе. Теперь мы сами используем этот интерфейс для отладки, когда что-то идет не так при запросах к целевым API.