Highlights
Du kannst Requests jetzt direkt im Dashboard erstellen, senden und wiederholen, unter Verwendung deines eigenen API Keys. Der neue Playground deckt alle drei Produkte ab und speichert Cookies, Presets sowie den Verlauf über mehrere Durchläufe hinweg. Parallel dazu wurden zwei Stabilitäts-Fixes eingespielt: unblocker: true war mehrere Wochen lang unbemerkt beeinträchtigt (funktioniert jetzt wieder End-to-End), und Browser erfasst das cf_clearance-Cookie der passiven Cloudflare-Challenges jetzt zuverlässig.
Was ist neu?
Der Dashboard-Playground
/dashboard/#playground ist jetzt eine vollwertige Workbench. Drei Produkt-Tabs (Single, Proxy Finder, Browser), eine URL-Leiste, Header, Body sowie alle produktspezifischen Flags, abgestimmt auf das jeweilige Schema. Sende den Request und sieh dir die Response in den Ansichtsmodi JSON, HTML oder Text an. Durchsuche Response-Panels mit Strg/Cmd+K. Maximiere die Response auf den gesamten Viewport, wenn du umfangreiches HTML analysieren musst.
Einige Features, die entstanden sind, weil wir das Tool selbst genau so nutzen wollten:
- Empfangene Cookies werden in einem Jar pro Host gespeichert. Der nächste Request an denselben Host hängt sie automatisch an. Du kannst jedes Cookie vor dem Senden prüfen, bearbeiten oder löschen.
- Eine Leiste für funktionierende Proxys sammelt jede Proxy-ID aus erfolgreichen Proxy Finder-Durchläufen. Mit einem Klick auf "use" kannst du diesen Proxy in einem Single- oder Browser-Request wiederverwenden, ohne ihn manuell einzugeben.
- Speichere Requests als Presets. Wiederhole jeden deiner letzten 20 Durchläufe direkt aus dem Verlaufsdialog.
- Ein cURL-Reproducer zeigt den exakten Befehl (inklusive
x-api-key), den du im Terminal ausführen müsstest, um denselben Request zu senden.
Der Playground signiert ein kurzlebiges internes Token, sodass dein Klartext-Key das Dashboard nie verlässt. Kontingente, Metriken und last_used_at werden wie gewohnt auf den ausgewählten Key angerechnet, genau wie bei einem Request aus deinem eigenen Code.
unblocker: true funktioniert wieder End-to-End
Wir haben ein Build-Problem behoben, das Single- und Proxy Finder-Requests mit unblocker: true in den letzten Wochen unbemerkt herabgestuft hatte. Der Build wurde ohne korrekt angebundenes Browser-Profil ausgeliefert. Requests, die eine Browser-Signatur hätten tragen sollen, erhielten stattdessen eine generische Request-Signatur. Websites, die den Zugriff hätten erlauben sollen, blockierten die Anfragen.
Der Fix ist deployed. Wir haben das Verhalten End-to-End an elf realen Zielen verifiziert, darunter drei hinter vorgeschalteten Prüfseiten, die zuvor Browser erforderten. Single passiert diese nun eigenständig. Der kombinierte Ablauf aus Proxy Finder + Browser + Single (Proxy finden, cf_clearance-Cookie über Browser abrufen, Page-Request mit Single inklusive Cookie und demselben Proxy senden) liefert das vollständige HTML in einem einzigen Roundtrip.
Dieser Fehler geht auf uns. unblocker: true funktionierte am Tag des Release und brach unbemerkt während eines Routine-Rebuilds. Wenn du in den letzten Wochen einen Request mit unblocker: true an eine geschützte Seite gesendet und einen 403 statt eines 200 erhalten hast, lag es daran. Versuch es noch einmal.
Browser verarbeitet die passive JavaScript-Challenge von Cloudflare
Cloudflare hat zwei Challenge-Modi. Den aktiven Modus (HTTP 403 plus Interstitial) haben wir bereits verarbeitet. Der passive Modus ist tückischer: Die Seite liefert sofort 200 zurück, aber Cloudflare schleust ein asynchrones JavaScript-Probe ein, das den Client fingerprintet und erst danach das cf_clearance Cookie setzt. Vor diesem Fix hat Browser die Response finalisiert, bevor das Probe abgeschlossen war. Das Clearance-Cookie landete also nie im Jar.
Browser wartet jetzt explizit auf das Set-Cookie Event und pausiert auf cf_clearance, wenn es den Marker für passive Challenges im Body erkennt. Kein Polling, keine feste Grace Period, keine zusätzliche Wartezeit für Nicht-Cloudflare-Sites. Zwölf reale Domains in der Testsuite, drei davon auf dem passiven Pfad, liefern Clearance-Cookies jetzt zuverlässig zurück.
SSRF-Lücke am API-Edge geschlossen
Ein gültiger pk_live_... API-Key berechtigt nicht zum Zugriff auf unser privates Netzwerk. Die API lehnt jetzt jedes Target ab, dessen Hostname-Literal oder DNS-Auflösung in einem nach RFC 5735, 6598 oder IPv6 reservierten Block landet. Dieselbe Prüfung läuft auf jedem Backend-Produkt als zweite Verteidigungslinie.
An der Oberfläche ändert sich für dich nichts. Wir schließen eine Klasse von internen Netzwerk-Probes, noch bevor sie einen TCP-Handshake abschließen können.
Blog erhält eigene Social Previews, Paginierung repariert
Jeder Blogpost generiert jetzt sein eigenes Open-Graph-Bild mit Titel und Excerpt auf einer Brand-Card. Wenn du einen foura.ai/blog/... Link in Discord, LinkedIn, Slack oder Twitter einfügst, siehst du die post-spezifische Vorschau statt eines generischen Fallbacks.
Die Paginierung im Blog-Index war unbemerkt defekt. Der Button "Ältere" hat dich zurück auf Seite 1 geführt. Wir haben sie auf pfadbasierte URLs (/blog/page/N/) umgestellt, eine nummerierte Navigation mit intelligentem Fenster integriert und saubere rel=prev/next Link-Tags für paginierte Serien ergänzt. Alte ?page=N URLs leiten per 301 auf das neue Format weiter, damit bereits gecrawlte Inhalte erhalten bleiben.
Under the Hood
Unser MCP-Server ist unter mcp.foura.ai für alle LLM-Tools erreichbar, die das Model Context Protocol unterstützen. Die Authentifizierung erfolgt über denselben pk_live_... Bearer-Token, den du für die REST-API nutzt. Er stellt die drei Produkte als Tools bereit (Single, Proxy Finder, Browser) sowie eine Handvoll Prompts. Wenn du FourA in Claude Code oder einen anderen MCP-fähigen Agenten einbindest, brauchst du keine lokale Bridge mehr.
Falls du das Dashboard bisher gemieden hast, weil der alte Playground unvollständig wirkte, schau es dir diese Woche an. Es ist die Oberfläche, die wir inzwischen selbst nutzen, wenn sich ein API-Target auffällig verhält.