Najważniejsze punkty
Możesz teraz tworzyć, wysyłać i powtarzać requesty przy użyciu własnego klucza API bezpośrednio w dashboardzie. Nowy playground obsługuje wszystkie trzy produkty i zachowuje cookie, presety oraz historię między uruchomieniami. Razem z nim wdrożyliśmy dwie poprawki stabilności: działanie unblocker: true po cichu degradowało przez kilka tygodni (teraz znów działa end-to-end), a Browser stabilnie przechwytuje teraz cookie cf_clearance z pasywnego wyzwania Cloudflare.
Co nowego
Dashboard Playground
/dashboard/#playground to teraz prawdziwy warsztat pracy. Trzy zakładki produktów (Single, Proxy Finder, Browser), pasek URL, nagłówki, body oraz wszystkie flagi dla poszczególnych produktów dopasowane do ich rzeczywistych schematów. Wyślij request i zobacz wyrenderowany response w trybie podglądu JSON, HTML lub tekstowym. Przeszukuj panele odpowiedzi za pomocą Ctrl/Cmd+K. Rozwiń response na pełny ekran, gdy musisz przeanalizować ścianę kodu HTML.
Kilka rzeczy, które wprowadziliśmy, bo sami chcielibyśmy z nich korzystać:
- Otrzymane cookie są zapisywane w kontenerze (jar) przypisanym do hosta. Kolejny request do tego samego hosta dołączy je automatycznie, a Ty możesz sprawdzić, edytować lub usunąć dowolne cookie przed wysyłką.
- Panel działających proxy zbiera każdy proxy id zwrócony z udanego uruchomienia Proxy Finder, więc możesz kliknąć „use” i użyć go ponownie w requeście Single lub Browser bez ręcznego przepisywania.
- Zapisuj requesty jako presety. Uruchamiaj ponownie dowolne z ostatnich 20 zapytań bezpośrednio z okna historii.
- Generator poleceń curl pokazuje dokładną komendę (z
x-api-key), którą możesz uruchomić w terminalu, aby wysłać taki sam request.
Playground podpisuje krótkożyciowy wewnętrzny token, dzięki czemu Twój klucz w postaci czystego tekstu nigdy nie opuszcza dashboardu. Użycie limitów, metryki oraz last_used_at są przypisywane do wybranego klucza dokładnie tak samo, jak przy wysyłaniu requestu z własnego kodu.
unblocker: true znów działa end-to-end
Wykryliśmy błąd w procesie budowania (build issue), który przez ostatnie kilka tygodni po cichu obniżał skuteczność requestów Single i Proxy Finder z flagą unblocker: true. Wersja produkcyjna została wydana bez podpiętego mechanizmu bypassu, przez co requesty, które powinny omijać zabezpieczenia antybotowe na poziomie handshake, otrzymywały generyczną sygnaturę requestu. Strony, które powinny nas przepuścić, blokowały nas.
Poprawka została wdrożona. Zweryfikowaliśmy działanie end-to-end na jedenastu rzeczywistych celach, w tym na trzech z ekranami oczekiwania (interstitials) Cloudflare, które wcześniej wymagały użycia Browser do przejścia. Teraz Single radzi sobie z nimi samodzielnie. Połączony przepływ Proxy Finder + Browser + Single (znajdź proxy, pobierz cookie cf_clearance z Browser, wyślij zapytanie o stronę przez Single z tym cookie i tym samym proxy) zwraca pełny kod HTML w jednym cyklu (round trip).
To nasza wpadka. unblocker: true działał w dniu wdrożenia i zepsuł się po cichu podczas rutynowego przebudowania projektu. Jeśli w ciągu ostatnich kilku tygodni wysłałeś request z unblocker: true do zabezpieczonej strony i zobaczyłeś błąd 403 zamiast kodu 200, to właśnie z tego powodu. Spróbuj ponownie.
Browser obsługuje pasywne wyzwania JavaScript od Cloudflare
Cloudflare ma dwa tryby wyzwań (challenges). Tryb aktywny (HTTP 403 i ekran oczekiwania) 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 bada sygnaturę (fingerprint) klienta i dopiero wtedy wystawia cookie cf_clearance. Przed tą poprawką Browser kończył obsługę odpowiedzi, zanim skrypt zdążył wykonać zadanie, przez co cookie uwierzytelniające nigdy nie trafiało do kontenera.
Browser nasłuchuje teraz bezpośrednio zdarzenia Set-Cookie i czeka na cf_clearance, jeśli w body wykryje znacznik pasywnego wyzwania. Bez odpytywania (polling), bez sztywnego czasu oczekiwania i bez opóźnień na stronach bez Cloudflare. Dwanaście rzeczywistych domen w pakiecie testowym, w tym trzy korzystające z pasywnej ścieżki, stabilnie zwraca teraz cookie uwierzytelniające.
Zamknięcie podatności SSRF na brzegu API
Ważny klucz API pk_live_... nie uprawnia do dostępu do naszej sieci prywatnej. API odrzuca teraz każdy cel, którego nazwa hosta lub wynik rozwiązania DNS (DNS resolution) wskazuje na bloki zarezerwowane RFC 5735, 6598 lub IPv6. Ta sama weryfikacja działa na każdym produkcie backendowym jako druga linia obrony.
Z zewnątrz nic się nie zmieni. Blokujemy całą klasę prób skanowania sieci wewnętrznej, zanim dojdzie do nawiązania połączenia TCP (handshake).
Unikalne podglądy social media dla bloga i poprawiona paginacja
Każdy wpis na blogu generuje teraz własny obraz Open Graph z tytułem i zajawką wyrenderowanymi na karcie marki. Wklej link foura.ai/blog/... na Discordzie, LinkedInie, Slacku lub Twitterze, a zobaczysz dedykowany podgląd wpisu zamiast domyślnego obrazka.
Paginacja na stronie głównej bloga po cichu nie działała. Przycisk „Older” cofał użytkownika na stronę 1. Przebudowaliśmy ją w oparciu o ścieżki URL (/blog/page/N/), dodaliśmy numerowaną nawigację z inteligentnym zakresem stron oraz odpowiednie tagi linków rel=prev/next dla serii stron. Stare adresy URL z ?page=N zwracają przekierowanie 301 na nowy format, więc roboty indeksujące nie stracą dotychczasowych danych.
Pod maską
Nasz serwer MCP działa pod adresem mcp.foura.ai dla wszelkich narzędzi LLM obsługujących Model Context Protocol. Uwierzytelnianie odbywa się za pomocą tego samego tokenu Bearer pk_live_..., którego używasz w REST API. Udostępnia on trzy produkty jako narzędzia (Single, Proxy Finder, Browser) oraz kilka gotowych promptów. Jeśli integrujesz FourA z Claude Code lub dowolnym agentem obsługującym MCP, nie musisz już uruchamiać lokalnego mostka.
Jeśli zwlekałeś z wejściem do dashboardu, bo poprzedni playground był tylko namiastką narzędzia, sprawdź go w tym tygodniu. To teraz to samo narzędzie, z którego sami korzystamy, gdy coś działa nie tak z docelowym API.