Highlights
Вече можете да съставяте, изпращате и повтаряте requests директно срещу собствения си API key в таблото. Новият playground покрива и трите продукта и запазва cookies, presets и историята между различните изпълнения. Заедно с това бяха внедрени две корекции за надеждност: unblocker: true тихомълком влошаваше работата си в продължение на няколко седмици (вече работи отново, end-to-end), а Browser вече улавя надеждно passive-challenge cf_clearance cookie-то на Cloudflare.
What's New
Dashboard Playground
/dashboard/#playground вече е истинска работна среда. Три продуктови раздела (Single, Proxy Finder, Browser), URL лента, headers, body, като всички флагове за всеки продукт са изложени и съобразени с неговата реална схема. Изпратете request, вижте как се рендира response с режими за преглед на JSON, HTML и текст. Търсете в панелите за response с Ctrl/Cmd+K. Разширете response в целия viewport, когато трябва да прочетете цяла стена от HTML.
Няколко неща, които се родиха от това, че го създадохме така, както ние самите бихме искали да го използваме:
- Получените cookies се записват в jar за конкретния хост. Следващият request към същия хост ги прикачва автоматично, като можете да преглеждате, редактирате или изтривате всяко cookie преди изпращане.
- Лентата с работещи proxies събира всяко proxy id, върнато от успешно изпълнение на Proxy Finder, така че можете да кликнете върху „use“ и да използвате повторно това proxy в Single или Browser request без повторно въвеждане.
- Запазвайте requests като presets. Повторете всяко от последните си 20 изпълнения от диалоговия прозорец за история.
- Инструмент за cURL възпроизвеждане показва точната команда (с
x-api-key), която бихте изпълнили от терминал, за да изпратите същия request.
Playground подписва краткотраен вътрешен token, така че вашият ключ в plain text никога не напуска таблото. Quota, metrics и last_used_at се отчитат към избрания от вас ключ по същия начин, по който биха се отчели, ако бяхте изпратили request от собствения си код.
unblocker: true работи отново, end-to-end
Установихме проблем с build-а, който тихомълком е влошавал Single и Proxy Finder requests с unblocker: true през последните няколко седмици. Версията беше пусната без реално свързан bypass, така че requests, които трябваше да преодолеят anti-bot защитите на ниво handshake, получаваха вместо това генеричен request signature. Сайтове, които трябваше да ни пропуснат, ни блокираха.
Корекцията е внедрена. Проверихме я end-to-end в единадесет реални цели, включително три с Cloudflare interstitials, които преди изискваха Browser за преодоляване. Single се справя с тях самостоятелно. Верижният поток Proxy Finder + Browser + Single (намиране на proxy, получаване на cf_clearance cookie от Browser, изпращане на page request със Single плюс cookie-то плюс същото proxy) връща пълен HTML в рамките на един round trip.
Грешката е наша. unblocker: true работеше в деня на пускането си и се счупи тихомълком по време на рутинен rebuild. Ако сте изпълнили request с unblocker: true срещу защитен сайт през последните няколко седмици и сте видели 403 там, където сте очаквали 200, това е причината. Опитайте отново.
Browser се справя с пасивното JavaScript предизвикателство на Cloudflare
Cloudflare има два режима на challenge. Активният режим (HTTP 403 плюс interstitial) вече се поддържаше от нас. Пасивният е по-коварен: страницата връща 200 веднага, но Cloudflare инжектира асинхронна JavaScript сонда, която прави fingerprint на клиента и едва тогава издава cf_clearance cookie-то. Преди тази корекция Browser завършваше response преди сондата да успее да приключи, така че clearance cookie-то никога не попадаше в jar-а.
Browser вече слуша изрично за събитието Set-Cookie и изчаква cf_clearance, ако види маркера за passive-challenge в body-то. Без polling, без фиксиран гратисен период, без допълнително чакане за сайтове извън Cloudflare. Дванадесет реални домейна в тестовия пакет, три от които по пасивния път, вече връщат надеждно clearance cookies.
Затворена SSRF пролука в API edge
Валиден pk_live_... API key не е разрешение за достъп до нашата частна мрежа. Сега API отхвърля всяка цел, чийто hostname литерал или DNS резолюция попада в резервиран блок по RFC 5735, 6598 или IPv6. Същата проверка се изпълнява във всеки backend продукт като втора линия на защита.
Няма да забележите нищо различно на повърхността. Затваряме цял клас от сканирания на вътрешната мрежа, преди те да успеят да завършат TCP handshake.
Блогът получава уникални social previews, пагинацията е коригирана
Всяка публикация в блога вече генерира свое собствено Open Graph изображение със заглавието и excerpt-а на публикацията, рендирани върху брандирана карта. Поставете връзка foura.ai/blog/... в Discord, LinkedIn, Slack или Twitter и ще видите специфичното за публикацията превю вместо общия fallback по подразбиране.
Пагинацията в индекса на блога беше тихомълком счупена. Бутонът „Older“ ви връщаше обратно на страница 1. Пренаписахме я с URLs, базирани на пътища (/blog/page/N/), добавихме номерирана навигация с интелигентен прозорец и добавихме правилни rel=prev/next link тагове за пагинирани серии. Старите ?page=N URLs пренасочват с 301 към новия формат, така че нищо, обходено преди това, не е загубено.
Under the Hood
Нашият MCP сървър е достъпен на mcp.foura.ai за всякакви LLM инструменти, които поддържат Model Context Protocol. Удостоверяването става със същия pk_live_... Bearer token, който използвате за REST API. Той излага трите продукта като инструменти (Single, Proxy Finder, Browser) и няколко prompts. Ако интегрирате FourA в Claude Code или друг агент с поддръжка на MCP, можете да спрете да използвате локален bridge.
Ако сте отлагали използването на таблото, защото предишният playground беше само загатване за функционалност, отворете го тази седмица. Това е интерфейсът, който ние самите използваме сега, когато нещо изглежда нередно при работа с API target.