Акценти
Вече можете да съставяте, изпращате и повтаряте заявки с вашия собствен API ключ директно в таблото за управление. Новият playground обхваща и трите продукта и запазва бисквитки, предварително зададени настройки и хронология между изпълненията. Заедно с него въведохме две корекции за надеждност: unblocker: true тихомълком деградираше в продължение на няколко седмици (вече работи отново изцяло), а Browser вече прихваща надеждно бисквитката cf_clearance от пасивните проверки на Cloudflare.
Какво е новото
Playground в таблото за управление
/dashboard/#playground вече е пълноценна работна среда. Три раздела за продукти (Single, Proxy Finder, Browser), адресна лента за URL, headers, body, както и всички специфични за продукта флагове, съобразени с актуалната схема на всеки продукт. Изпратете заявката и вижте как отговорът се визуализира с режими за преглед на JSON, HTML и текст. Търсете в панелите за отговор с Ctrl/Cmd+K. Разгънете отговора на цял екран, когато трябва да прегледате голям обем HTML код.
Няколко възможности, които създадохме така, както самите ние бихме искали да ги ползваме:
- Получените бисквитки се запазват в хранилище за всеки отделен хост. Следващата заявка към същия хост ги прикачва автоматично, като можете да преглеждате, редактирате или изтривате всяка бисквитка преди изпращане.
- Списъкът с работещи проксита събира всяко proxy id, върнато от успешно изпълнение на Proxy Finder, така че да можете да кликнете "use" и да използвате повторно това прокси в заявка към Single или Browser без повторно въвеждане.
- Запазвайте заявките като шаблони. Повтаряйте всяко от последните си 20 изпълнения от диалоговия прозорец за хронология.
- Инструментът за възпроизвеждане с curl показва точната команда (с
x-api-key), която бихте изпълнили от терминала за изпращане на същата заявка.
Playground генерира краткотраен вътрешен токен, така че вашият ключ в чист текст никога не напуска таблото за управление. Квотите, метриките и last_used_at се отчитат към избрания от вас ключ по същия начин, както ако бяхте изпратили заявката от собствен код.
unblocker: true работи отново изцяло
Открихме проблем при компилацията, който тихомълком е понижавал качеството на заявките в Single и Proxy Finder с unblocker: true през последните няколко седмици. Версията е била пусната без реално интегриран профил на браузъра, поради което заявки, които е трябвало да носят браузърен подпис, са получавали генеричен подпис за заявка. Сайтове, които е трябвало да ни пропуснат, ни блокираха.
Корекцията е качена. Проверихме функционалността изцяло при единадесет реални цели, включително три зад страници за проверка, които преди изискваха Browser. Single ги преминава самостоятелно. Свързаният работен процес Proxy Finder + Browser + Single (намиране на прокси, получаване на бисквитка cf_clearance от Browser, изпращане на заявка за страницата със Single плюс бисквитката и същото прокси) връща пълен HTML в рамките на едно изпълнение.
Грешката е изцяло наша. unblocker: true работеше в деня на пускането и се повреди незабелязано при рутинна повторна компилация. Ако сте изпълнили заявка с unblocker: true към защитен сайт през последните няколко седмици и сте получили статус 403 вместо очаквания 200, причината е тази. Опитайте отново.
Browser обработва пасивното JavaScript предизвикателство на Cloudflare
Cloudflare има два режима на проверка. Активният режим (HTTP 403 плюс междинна страница) вече се поддържаше. Пасивният е по-коварен: страницата връща 200 веднага, но Cloudflare инжектира асинхронен JavaScript скрипт, който снема отпечатък на клиента и едва тогава издава cf_clearance бисквитката. Преди тази корекция Browser финализираше отговора преди скриптът да завърши, така че clearance бисквитката никога не попадаше в хранилището.
Browser вече следи изрично за събитието Set-Cookie и изчаква cf_clearance, ако открие маркера за пасивна проверка в тялото. Без polling, без фиксиран период на изчакване, без допълнително забавяне за сайтове извън Cloudflare. Дванадесет реални домейна в тестовия пакет, три от тях по пасивния път, вече надеждно връщат clearance бисквитки.
Затворена SSRF уязвимост на ниво API edge
Валиден pk_live_... API ключ не е разрешение за достъп до нашата частна мрежа. API вече отхвърля всяка цел, чийто точен hostname или DNS резолюция попада в резервиран блок по RFC 5735, 6598 или IPv6. Същата проверка се изпълнява при всеки backend продукт като втора защитна линия.
Няма да забележите промяна на повърхността. Пресичаме цял клас сканирания на вътрешната мрежа още преди завършването на TCP handshake.
Блогът получава уникални визуализации за социални мрежи, пагинацията е оправена
Всяка публикация в блога вече генерира собствено Open Graph изображение със заглавието и откъс от текста, форматирани върху брандирана карта. Поставете foura.ai/blog/... връзка в Discord, LinkedIn, Slack или Twitter и ще видите специфична за публикацията визуализация вместо стандартното общо изображение.
Пагинацията в индекса на блога имаше скрит дефект. Бутонът "Older" връщаше обратно на страница 1. Преработихме я с URL адреси, базирани на пътища (/blog/page/N/), добавихме номерирана навигация с адаптивен прозорец и въведохме коректни rel=prev/next link тагове за пагинирани поредици. Старите ?page=N URL адреси се пренасочват с 301 към новия формат, така че нищо индексирано преди това не се губи.
Под капака
Нашият MCP сървър е достъпен на mcp.foura.ai за всички LLM инструменти, поддържащи Model Context Protocol. Удостоверяването става със същия pk_live_... Bearer токен, който използвате за REST API. Той предоставя трите продукта като инструменти (Single, Proxy Finder, Browser) и няколко prompt шаблона. Ако интегрирате FourA в Claude Code или друг агент с MCP поддръжка, вече няма нужда да пускате локален bridge.
Ако сте отлагали използването на таблото за управление, защото предишният playground беше само базова демонстрация, отворете го тази седмица. Това е интерфейсът, който самите ние вече използваме, когато нещо изглежда нередно при заявка към дадена API цел.