Änderungsprotokoll

Activity passt nun ohne horizontales Scrollen auf ein 14" MacBook, und jede Spalte behält ihren Wert. Das Detail-Panel hat jetzt Tabs (Request, Response-Header, Response-Body), sodass die Antwort oben steht, statt 900px weiter unten. Tooltips folgen deinem Mauszeiger und zeigen die vollständige URL an.

Die Methoden-Spalte liest nun das Verb aus deinem Request-Body (GET, POST, PUT, etc.), anstatt immer POST anzuzeigen, weil unser API-Layer dies empfangen hat. Playground-Aufrufe erfassen auch die Browser-IP der Person, die auf Senden geklickt hat. So können geteilte Accounts nachvollziehen, wer was ausgeführt hat.

Mit FourA MCP 0.6.0 kann ein Agent wählen, welchen Browser ein Request präsentiert. foura_single und foura_proxy akzeptieren browser, os, version oder eine genaue profile ID aus dem öffentlichen Katalog unter GET /api/profiles. Sie werden im Request mitgeschickt, der bereits upstream geht, es gibt also keinen zusätzlichen Aufruf. Wenn du sie weglässt, präsentiert der Request den neuesten Google Chrome, genau wie zuvor. Eine Kombination, die der Katalog nicht präsentieren kann, liefert einen Fehler mit den verfügbaren Optionen zurück. Ein Request wird also nie als ein Browser gesendet, den du nicht ausgewählt hast.

Beide Tools geben nun defense zurück, wenn das Ziel einen Bot-Check durchgeführt hat. defense.solved: false bedeutet, dass der Body eine Challenge-Seite statt des angeforderten Inhalts sein kann. Dies ist das Signal, es mit einem anderen Browser erneut zu versuchen oder zu eskalieren, anstatt eine Block-Seite als Daten zu parsen.

Eine Korrektur im selben Release: Die Beschreibung von unblocker besagte, dass der Standardwert aus war. Er war schon immer an, daher enthielten Requests bereits ein vollständiges Browser-Header-Set. Das veröffentlichte Schema entspricht nun diesem Verhalten.

Eine überlastete Instanz beantwortet einen Health Check in 3 bis 10 Sekunden, während eine gesunde 9 bis 225 Millisekunden benötigt. Bisher galten beide als in Ordnung. Langsam gilt jetzt als beeinträchtigt und übermittelt den eigenen Grund der Instanz. So erkennen wir das Problem, solange es nur ein einzelner langsamer Server und noch nicht dein fehlgeschlagener Request ist. Auto wird ebenfalls überwacht. Die Limits sind darauf eingestellt, wie lange ein echtes, schweres Solve dauert, anstelle eines generischen Limits, das bei jedem Erfolg auslösen würde.

Der Parameter profile teilt dem Unblocker mit, als welcher Browser er sich bei /api/single und /api/proxy ausgeben soll. Übergib eine exakte Profil-ID (wie firefox147 oder chrome146) oder lass browser + os + version zur neuesten passenden Kombination auflösen. GET /api/profiles gibt den aktuellen Katalog zurück (79 Profile über fünf Browser-Familien), damit du keine veraltende Liste hardcodest. Der Dashboard-Playground bietet denselben Picker in Form von drei kaskadierenden Selects.

Der Dashboard Playground bietet jetzt drei kaskadierende Auswahlmenüs für OS, Browser und Version, die live aus dem Profilkatalog geladen werden. Wähle zwei beliebige aus und die dritte Auswahl wird auf die tatsächlich verfügbaren Optionen eingegrenzt. Die Auswahl eines Profils aktiviert unblocker, da die API ein Profil ohne diese Einstellung ablehnt.

Ein Service gilt jetzt nur noch als ausgefallen, wenn er jede Instanz verloren hat, der einzige Zustand, in dem dein Request nirgendwo landen kann. Routinemäßige Rolling Deploys werden nicht mehr als Vorfälle auf der Statusseite angezeigt.

Die vom Unblocker gesendete Standard-Signatur ist jetzt eine aktuelle Major-Version und nicht mehr die alte, die Scraper fest codiert hatten. Websites, die bei älteren Major-Versionen statische Block-Seiten zurückgegeben haben, liefern auf Single und Browser wieder ihre echte Seite aus. Beide Produkte wurden zusammen aktualisiert. Ein cf_clearance Replay von Browser zu Single ist also weiterhin Byte für Byte identisch.

Wenn deine Bank bei einem Plan-Upgrade nach 3D Secure gefragt hat, hat der Request auf eine Änderung gepollt, die nie eintraf (niemand hat dich zur Authentifizierung aufgefordert). Der Flow zur Planänderung verarbeitet den zusätzlichen Schritt nun wie beim ersten Abonnieren, sodass das Upgrade erfolgreich durchgeführt wird.

Wenn ein Admin dir einen benutzerdefinierten Plan zuweist, wird dieser nun unter Abrechnung / Plan als 'Dein benutzerdefinierter Plan: {name} ({price})' mit einem Button zum Abonnieren angezeigt. Zuvor war die Zuweisung unsichtbar, bis dir jemand von ihrer Existenz erzählt hat.

Bisher hat Browser die Stufe von 30 Credits für überwundenen Schutz nur berechnet, wenn ein Cloudflare Clearance-cookie auftauchte. Jetzt gilt das Gleiche für jeden Schutz, den wir erkennen und überwinden, angefangen bei SiteGround. Die Response enthält außerdem defenses: { present, cleared }, sodass du erkennen kannst, welcher Anbieter im Weg war, selbst wenn wir ihn noch nicht überwunden haben (DataDome, PerimeterX, Akamai, Incapsula und hCaptcha werden aktuell erkannt, aber noch nicht überwunden).

Browser-Responses geben nun defenses: { present, cleared } zurück: jeden Vendor, den das Ziel ausführte, und jeden, den wir tatsächlich umgangen haben. Die Abrechnung folgt der gleichen Regel. Ein Request, der einen Vendor (nicht nur Cloudflare) umgeht, gilt als Defense Solve, und Vendoren, die wir erkennen, aber noch nicht überwinden können, erscheinen in present und erhöhen den Preis nie.

SiteGround steht vor einem großen Teil kleiner WordPress- und WooCommerce-Shops, daher ist der Robot Challenge Screen eine Klasse von Zielen und nicht nur eine Website. Mit unblocker: true löst Single dies nun in-process und gibt die echte Seite zurück. Zuvor musstest du Browser für diese Zielklasse starten, was bedeutete, dass du für eine Browser-Sitzung und die Wartezeit bezahlen musstest. Das Clearance-Cookie wird in der Response zurückgegeben, sodass ein Replay günstig bleibt.

Der Browser verarbeitet nun Challenge-Seiten, die weiterleiten, bevor ihr Body gelesen werden kann. So erhalten Requests an geschützte Seiten Inhalt statt einer leeren Response.

SiteGround schaltet einen 'Robot Challenge Screen' vor viele kleine WordPress und WooCommerce Shops. Es gibt nichts zum Klicken, es ist ein SHA-1 Proof of Work. Single löst dies nun in einem Call und liefert die echte Seite zurück, für 2 Credits statt einer Browser-Session für 30 Credits. Es ist die erste Abwehr abseits von Cloudflare, die Single eigenständig bewältigt.