Najważniejsze zmiany
Możesz teraz tworzyć, wysyłać i odtwarzać żądania z użyciem własnego klucza API bezpośrednio w dashboardzie. Nowy playground obsługuje wszystkie trzy produkty i zachowuje pliki cookie, presety oraz historię między uruchomieniami. Wraz z nim wdrożyliśmy dwie poprawki niezawodności: funkcja unblocker: true działała gorzej przez kilka tygodni bez widocznych błędów (znów działa poprawnie, end-to-end), a Browser niezawodnie przechwytuje teraz cookie pasywnego challenge'u Cloudflare cf_clearance.
Co nowego
Dashboard Playground
/dashboard/#playground to teraz pełnoprawne środowisko pracy. Trzy zakładki produktów (Single, Proxy Finder, Browser), pasek adresu URL, nagłówki, treść żądania oraz wszystkie flagi per produkt dopasowane do rzeczywistego schematu każdego z nich. Wyślij żądanie i obserwuj renderowanie odpowiedzi w trybach widoku JSON, HTML oraz tekstu. Przeszukuj panele odpowiedzi za pomocą Ctrl/Cmd+K. Rozwiń odpowiedź na cały ekran, gdy musisz przejrzeć długi kod HTML.
Kilka rozwiązań, które powstały, ponieważ sami chcieliśmy z nich korzystać:
- Otrzymane pliki cookie są zapisywane w magazynie per host. Kolejne żądanie do tego samego hosta dołącza je automatycznie, a Ty możesz sprawdzić, edytować lub usunąć dowolne cookie przed wysłaniem.
- Pasek działających proxy gromadzi wszystkie identyfikatory proxy zwrócone przez udane uruchomienie Proxy Finder. Możesz kliknąć "use" i użyć tego proxy w żądaniu Single lub Browser bez ponownego wpisywania.
- Zapisuj żądania jako presety. Odtwarzaj dowolne z ostatnich 20 uruchomień z poziomu okna historii.
- Generator cURL wyświetla dokładne polecenie (z
x-api-key), które możesz uruchomić w terminalu, aby wysłać to samo żądanie.
Playground podpisuje krótkotrwały wewnętrzny token, więc Twój klucz w jawnym tekście nigdy nie opuszcza dashboardu. Limit, metryki i last_used_at obciążają wybrany klucz dokładnie tak samo, jak w przypadku wysłania żądania z własnego kodu.
unblocker: true działa ponownie, end-to-end
Wykryliśmy błąd w procesie budowania, który przez ostatnie kilka tygodni po cichu degradował żądania Single i Proxy Finder z flagą unblocker: true. Wersja została wdrożona bez podpiętego profilu przeglądarki, więc żądania, które powinny mieć sygnaturę przeglądarki, otrzymywały zwykłą sygnaturę żądania. Witryny, które powinny nas przepuścić, blokowały ruch.
Poprawka jest wdrożona. Zweryfikowaliśmy działanie end-to-end na jedenastu rzeczywistych celach, w tym na trzech ze stronami weryfikacyjnymi, które wcześniej wymagały produktu Browser. Single radzi sobie z nimi samodzielnie. Połączony przepływ Proxy Finder + Browser + Single (znajdź proxy, pobierz cookie cf_clearance z Browser, wyślij żądanie strony przez Single z tym cookie i tym samym proxy) zwraca pełny kod HTML w ramach jednego cyklu.
To nasz błąd. Funkcja unblocker: true działała w dniu wdrożenia i zepsuła się po cichu podczas rutynowej przebudowy. Jeśli w ostatnich tygodniach wysyłałeś żądanie z unblocker: true do chronionej witryny i otrzymałeś kod 403 zamiast oczekiwanego 200, to było powodem. Spróbuj ponownie.
Browser obsługuje pasywny JavaScript challenge Cloudflare
Cloudflare ma dwa tryby challenge. Tryb aktywny (HTTP 403 oraz strona pośrednia) obsługiwaliśmy już wcześniej. Tryb pasywny jest bardziej podstępny: strona natychmiast zwraca kod 200, ale Cloudflare wstrzykuje asynchroniczny skrypt JavaScript, który zbiera fingerprint klienta i dopiero wtedy wystawia cookie cf_clearance. Przed tą poprawką Browser finalizował response, zanim sonda zdążyła zakończyć działanie, przez co cookie clearance nigdy nie trafiało do magazynu.
Browser nasłuchuje teraz bezpośrednio zdarzenia Set-Cookie i czeka na cf_clearance, jeśli wykryje znacznik pasywnego challenge w treści. Bez pollingu, bez sztywnego czasu oczekiwania i bez dodatkowych opóźnień dla stron spoza Cloudflare. Dwanaście rzeczywistych domen w zestawie testowym, w tym trzy korzystające ze ścieżki pasywnej, zwraca teraz stabilnie pliki cookie clearance.
Zamknięta luka SSRF na brzegu API
Prawidłowy klucz API pk_live_... nie daje uprawnień do sięgania do naszej sieci prywatnej. API odrzuca teraz każdy cel, którego nazwa hosta lub wynik rozpoznawania DNS wskazuje na bloki zastrzeżone w RFC 5735, 6598 lub IPv6. To samo sprawdzenie działa w każdym produkcie backendowym jako druga linia obrony.
Z zewnątrz nie widać żadnych zmian. Blokujemy całą klasę prób skanowania sieci wewnętrznej, zanim zdążą one nawiązać połączenie TCP.
Blog otrzymuje unikalne podglądy społecznościowe, naprawiono paginację
Każdy wpis na blogu generuje teraz własny obraz Open Graph z tytułem i fragmentem wpisu wyrenderowanymi na karcie marki. Po wklejeniu linku foura.ai/blog/... na Discordzie, LinkedInie, Slacku lub Twitterze zobaczysz podgląd dedykowany dla danego posta zamiast generycznego obrazu zastępczego.
Paginacja na stronie głównej bloga po cichu nie działała prawidłowo. Przycisk "Older" cofał użytkownika na stronę 1. Przebudowaliśmy ją w oparciu o adresy URL ze ścieżkami (/blog/page/N/), dodaliśmy numerowaną nawigację z inteligentnym zakresem oraz właściwe tagi linków rel=prev/next dla serii paginowanych. Stare adresy URL ?page=N przekierowują kodem 301 na nową strukturę, więc zaindeksowane wcześniej zasoby nie przepadną.
Pod maską
Nasz serwer MCP jest dostępny pod adresem mcp.foura.ai dla wszystkich narzędzi LLM obsługujących Model Context Protocol. Uwierzytelnianie opiera się na tym samym tokenie Bearer pk_live_..., którego używasz w REST API. Udostępnia on trzy produkty jako narzędzia (Single, Proxy Finder, Browser) oraz zestaw promptów. Jeśli integrujesz FourA z Claude Code lub dowolnym agentem obsługującym MCP, nie musisz już uruchamiać lokalnego mostu.
Jeśli dotąd omijałeś panel, bo wcześniejszy playground był zaledwie szkicem, sprawdź go w tym tygodniu. To ten sam interfejs, z którego sami korzystamy, gdy coś wygląda nie tak przy wywołaniach API.