Highlights
Du kannst jetzt Requests direkt im Dashboard erstellen, senden und mit deinem eigenen API-Key wiederholen. Der neue Playground deckt alle drei Produkte ab und speichert Cookies, Presets und den Verlauf über verschiedene Durchläufe hinweg. Zwei Zuverlässigkeits-Fixes wurden parallel veröffentlicht: unblocker: true war einige Wochen lang unbemerkt beeinträchtigt (es funktioniert wieder End-to-End), und Browser erfasst den passiven Challenge-Cookie cf_clearance von Cloudflare jetzt zuverlässig.
Neuigkeiten
Der Dashboard-Playground
/dashboard/#playground ist jetzt eine echte Werkbank. Drei Produkt-Tabs (Single, Proxy Finder, Browser), eine URL-Leiste, Header, Body und alle produktspezifischen Flags, die offengelegt und an das tatsächliche Schema des jeweiligen Produkts angepasst sind. Sende den Request und sieh dir die gerenderte Response in den Ansichtsmodi JSON, HTML und Text an. Suche mit Strg/Cmd+K in allen Response-Fenstern. Vergrößere die Response auf den gesamten Viewport, wenn du eine ganze Wand aus HTML lesen musst.
Einige Details, die entstanden sind, weil wir das Tool so gebaut haben, wie wir es selbst nutzen möchten:
- Cookies, die du empfängst, werden in einem Cookie-Jar pro Host gespeichert. Der nächste Request an denselben Host hängt sie automatisch an, und du kannst jeden Cookie vor dem Senden prüfen, bearbeiten oder löschen.
- Eine Seitenleiste für aktive Proxys sammelt jede Proxy-ID, die bei einem erfolgreichen Proxy Finder-Durchlauf zurückgegeben wurde, sodass du auf „Nutzen“ klicken und diesen Proxy in einem Single- oder Browser-Request wiederverwenden kannst, ohne ihn neu einzutippen.
- Speichere Requests als Presets. Wiederhole jeden deiner letzten 20 Durchläufe über einen Verlaufsdialog.
- Ein cURL-Reproduzierer zeigt den exakten Befehl (mit
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. Kontingent, Metriken und last_used_at werden auf den von dir ausgewählten Key angerechnet, genau wie beim Senden des Requests aus deinem eigenen Code.
unblocker: true funktioniert wieder End-to-End
Wir haben ein Build-Problem behoben, das in den letzten Wochen Single- und Proxy Finder-Requests mit unblocker: true unbemerkt beeinträchtigt hatte. Der Build wurde ausgeliefert, ohne dass der Bypass tatsächlich integriert war, sodass Requests, die Anti-Bot-Sperren auf Handshake-Ebene hätten umgehen sollen, stattdessen eine generische Request-Signatur erhielten. Websites, die uns hätten durchlassen sollen, blockierten uns.
Der Fix ist eingespielt. Wir haben das End-to-End bei elf realen Zielen verifiziert, darunter drei mit Cloudflare-Interstitials, für die zuvor Browser erforderlich war. Single bewältigt diese nun im Alleingang. Der verkettete Ablauf aus Proxy Finder + Browser + Single (Proxy finden, cf_clearance-Cookie von Browser abrufen, Seiten-Request mit Single plus Cookie plus demselben Proxy senden) liefert das vollständige HTML in einem einzigen Roundtrip zurück.
Das geht auf unsere Kappe. unblocker: true funktionierte am Tag der Auslieferung und ging bei einem routinemäßigen Rebuild unbemerkt kaputt. Wenn du in den letzten Wochen einen Request mit unblocker: true gegen eine geschützte Website ausgeführt und einen 403 statt des erwarteten 200 erhalten hast, war das der Grund. Versuche es noch einmal.
Browser bewältigt die passive JavaScript-Challenge von Cloudflare
Cloudflare hat zwei Challenge-Modi. Den aktiven Modus (HTTP 403 plus Interstitial) haben wir bereits unterstützt. Der passive Modus ist tückischer: Die Seite gibt sofort 200 zurück, aber Cloudflare schleust ein asynchrones JavaScript-Probe-Skript ein, das den Client per Fingerprinting erfasst und erst danach den cf_clearance-Cookie ausstellt. Vor diesem Fix schloss Browser die Response ab, bevor das Probe-Skript fertiggestellt war, sodass der Clearance-Cookie nie im Cookie-Jar landete.
Browser lauscht jetzt explizit auf das Set-Cookie-Event und wartet auf cf_clearance, wenn er den Marker für die passive Challenge im Body erkennt. Kein Polling, keine feste Kulanzzeit, keine zusätzliche Wartezeit für Websites, die nicht auf Cloudflare laufen. Zwölf reale Domains in der Test-Suite, davon drei 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 ist keine Lizenz, um auf unser privates Netzwerk zuzugreifen. Die API lehnt nun jedes Ziel ab, dessen Hostname-Literal oder DNS-Auflösung in einem für RFC 5735, 6598 oder IPv6 reservierten Block liegt. Derselbe Check läuft bei jedem Backend-Produkt als zweite Verteidigungslinie.
Oberflächlich wirst du keinen Unterschied bemerken. Wir unterbinden eine ganze Kategorie von internen Netzwerk-Probes, noch bevor sie einen TCP-Handshake abschließen können.
Blog erhält individuelle Social-Previews, Pagination behoben
Jeder Blog-Post generiert jetzt sein eigenes Open-Graph-Bild, bei dem Titel und Excerpt des Beitrags auf einer Brand-Card gerendert werden. Wenn du einen Link wie foura.ai/blog/... in Discord, LinkedIn, Slack oder Twitter einfügst, siehst du die beitragsbezogene Vorschau anstelle eines generischen Fallbacks.
Die Pagination auf der Blog-Übersichtsseite war unbemerkt fehlerhaft. Der Button „Ältere“ leitete dich zurück auf Seite 1. Wir haben sie auf pfadbasierte URLs (/blog/page/N/) umgestellt, eine nummerierte Navigation mit intelligentem Ausschnitt hinzugefügt und korrekte rel=prev/next-Link-Tags für paginierte Serien implementiert. Alte ?page=N-URLs werden per 301 auf das neue Format weitergeleitet, sodass zuvor gecrawlte Inhalte nicht verloren gehen.
Unter der Haube
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 auch für die REST-API verwendest. Er stellt die drei Produkte als Tools (Single, Proxy Finder, Browser) sowie eine Handvoll Prompts bereit. Wenn du FourA in Claude Code oder einen anderen MCP-fähigen Agenten einbindest, musst du keine lokale Bridge mehr betreiben.
Wenn du das Dashboard bisher gemieden hast, weil der vorherige Playground nur ein schwacher Ansatz war, solltest du es diese Woche öffnen. Es ist mittlerweile die Oberfläche, die wir selbst nutzen, wenn bei einem API-Ziel etwas nicht stimmt.