Highlights
Browser-Profile lassen sich jetzt pro Request festlegen. Gib den gewünschten Browser und das OS an, und der Fingerprint sowie die Headers spiegeln genau das wider. Single hat diese Woche gelernt, zwei weitere Abwehrmechanismen (SiteGrounds SG-Captcha und eBays Argon2-Challenge) zu lösen, ohne Browser zu starten. Zudem protokolliert die Activity-Ansicht im Dashboard nun deine tatsächliche Anfrage und nicht die darunterliegende Technik.
Neuigkeiten
Wähle dein Browser-Profil pro Request
Bisher wählte unblocker: true eine Signatur aus (unseren jeweiligen Standard) und das war es. Jetzt kannst du eine explizit angeben:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
oder frage nach einem Browser- und OS-Paar:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
Die API weist unbekannte Kombinationen nach Namen ab und listet auf, was verfügbar IST. Ein Tippfehler kann also nicht heimlich eine Signatur ausliefern, die du nie angefordert hast.
Der gesamte Katalog liegt unter GET /api/profiles. Er ist öffentlich (kein Key nötig), da es sich um eine Funktionsliste und nicht um ein Geheimnis handelt. Zum Zeitpunkt des Schreibens gibt es 79 Presets über Chrome, Firefox, Edge, Safari und Tor hinweg, auf Windows, macOS, Android und iOS. Der Playground liest aus derselben Liste. Das Dropdown zeigt also immer genau das, was dein Code anfragen kann.
Warum das wichtig ist: Wenn dein Ziel Requests nach OS profiliert, oder dein Team durch A/B-Tests prüft, welcher Stack eine bestimmte Sperre überwindet, hältst du diese Variable nun konstant, während sich alles andere ändert.
Single löst SG-Captcha und eBay Proof-of-Work
Zwei Abwehrmaßnahmen, die früher einen Umweg über Browser erzwangen, werden nun von Single gelöst. eBay liefert eine eigene Proof-of-Work Challenge (ein Argon2-Puzzle) und SiteGround schützt einen Teil des Shared-Hosting-Webs mit SG-Captcha. Beide lösen ohne Rendering. Die Response kommt also in Form eines einzigen HTTP Requests zurück und wird entsprechend abgerechnet.
Das Defense-Signal in Responses wurde ebenfalls erweitert. Browser Responses enthalten nun defenses: { present, cleared }. Du kannst also sehen, welcher Vendor vor der Seite saß und ob wir durchgekommen sind. Das Billing folgt derselben Regel: Jeder Vendor, den wir überwinden, wird zugeordnet, unabhängig von der Marke. Cloudflare war vor diesem Fenster die einzige kostenpflichtige Lösung. Akamai Bot Manager, SG-Captcha und die Challenge von eBay stehen nun direkt daneben.
Activity-Ansicht im Dashboard neu aufgebaut
Zwei Spalten in der Activity-Liste des Dashboards zeigten etwas Falsches an. Die HTTP-Methode lautete in jeder Zeile POST (alle unsere Endpoints sind POST, die Spalte war also eine Konstante ohne Aussagekraft). Die Client-IP bei Playground-Aufrufen zeichnete auf, von wo der Playground aufrief, und nicht die Person, die auf Run klickte.
Beides ist behoben. Die Methoden-Spalte zeigt nun das Verb, das du im Request Body gesendet hast. Die Client-IP in Playground-Zeilen zeigt jetzt die Browser-IP des angemeldeten Nutzers. Sie wird in einem signierten Playground Token übergeben, sodass ein API Client sie nicht fälschen kann.
Der Rest der Ansicht wurde bei dieser Gelegenheit ebenfalls neu aufgebaut. Die Tabelle passt auf einen Laptop, ohne Spalten zu verbergen. Die Produkt-Spalte klappt in die Request-Zeile ein. Das Detail-Panel hat Tabs erhalten, sodass Request, Response und Defense-Zusammenfassung jeweils einzeln scrollbar sind.
Billing: 3D Secure beim Plan-Wechsel
Wenn dein Kartenaussteller eine 3DS-Bestätigung für einen Plan-Wechsel forderte (nicht nur bei der initialen Anmeldung), wurde dieser Schritt nicht ausgelöst und die Änderung stillschweigend rückgängig gemacht. Jetzt wird er ausgelöst. Wenn du im letzten Monat versucht hast, den Plan zu wechseln, und scheinbar nichts passiert ist, lag es daran.
Unter der Haube
Der Playground weigert sich, einen Response Header aus den Daten einer abgerufenen Seite zu erstellen (eine Klasse von Header-Injection-Bugs, die wir frühzeitig erkannt haben). Ein Billing Endpoint im Dashboard verifiziert vor der Antwort, ob dem Aufrufer die Ressource gehört, und schließt so einen IDOR-Pfad.
Die Deploy Pipeline selbst hat nach einem Ausfall am 6. eine Woche lang Fixes erhalten. Damals lief die Festplatte des Deploy Hosts mitten im Build voll. Jeder Service weigert sich ohne Disk Headroom zu bauen. Deploys werden serialisiert, statt zu konkurrieren. Das Gateway bleibt online, wenn ein Backend wackelt, und Services beenden sich tatsächlich bei SIGTERM, anstatt zu hängen, bis sie dreißig Sekunden später beendet werden.
Lange Zeit war "welche Browser-Signatur" eine Entscheidung, die wir für dich getroffen haben. Das muss nicht so sein.