Highlights
Die Auswahl des Browser-Profils ist jetzt eine Option pro Request. Gib den gewünschten Browser und das OS an, und Fingerprint sowie Header stimmen überein. Single kann diese Woche zwei weitere Checks ausführen (die rechnerischen Prüfungen von SiteGround und eBay), ohne Browser zu starten. Und die Activity-Ansicht im Dashboard zeichnet jetzt auf, was du angefordert hast, nicht die zugrunde liegende Infrastruktur.
Neuheiten
Wähle dein Browser-Profil pro Request
Bisher hat unblocker: true eine feste Signatur gewählt (unseren jeweiligen Standard). Jetzt kannst du sie selbst bestimmen:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
oder frage nach einer Kombination aus Browser und OS:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
Die API weist unbekannte Kombinationen namentlich ab und listet auf, was verfügbar IST. So kann ein Tippfehler nicht unbemerkt eine Signatur ausliefern, nach der du nie gefragt hast.
Der vollständige Katalog liegt unter GET /api/profiles. Er ist öffentlich (kein Key erforderlich), da es sich um eine Funktionsliste und kein Geheimnis handelt. Zum Zeitpunkt dieses Beitrags gibt es 79 Presets für Chrome, Firefox, Edge, Safari und Tor unter Windows, macOS, Android und iOS. Der Playground liest dieselbe Liste, sodass das Dropdown-Menü immer genau das anzeigt, was dein Code anfordern kann.
Warum das wichtig ist: Wenn dein Ziel Requests nach Betriebssystem profiliert oder dein Team per A/B-Test prüft, welcher Stack eine bestimmte Hürde überwindet, kannst du diese Variable nun konstant halten, während sich alles andere ändert.
Single bewältigt die Rechenprüfungen von SiteGround und eBay
Zwei Schutzmechanismen, die zuvor einen Umweg über Browser erzwangen, laufen nun direkt über Single. eBay nutzt eine eigene Proof-of-Work-Challenge (ein Argon2-Puzzle) und SiteGround führt eine eigene Prüfung über Teile des Shared-Hosting-Webs durch. Beide werden ohne Rendering gelöst. Das bedeutet, dass die Response als einzelner HTTP-Request zurückkommt und entsprechend abgerechnet wird.
Das Abwehrsignal in Responses wurde ebenfalls erweitert. Browser-Responses enthalten jetzt defenses: { present, cleared }, sodass du siehst, welcher Anbieter vor der Seite lag und ob wir durchgekommen sind. Die Abrechnung folgt derselben Regel: Jeder Anbieter, den wir überwinden, wird zugeordnet, ganz gleich, um welche Marke es sich handelt. Vor diesem Update wurde nur ein Prüfdienst als interaktive Seite abgerechnet. Drei weitere sind nun dazugekommen.
Aktivitätsansicht im Dashboard überarbeitet
Zwei Spalten in der Aktivitätsliste des Dashboards zeigten falsche Daten. Die HTTP-Methode stand in jeder Zeile auf POST (alle unsere Endpoints sind POST, die Spalte bot also keinen Informationswert). Und die Client-IP bei Playground-Aufrufen zeigte an, von wo aus der Playground den Aufruf startete, nicht die IP des Nutzers, der auf Run klickte.
Beides ist behoben. Die Methodenspalte zeigt jetzt das Verb an, das du im Request-Body gesendet hast. Die Client-IP in Playground-Zeilen zeigt nun die Browser-IP des angemeldeten Nutzers. Sie wird in einem signierten Playground-Token übertragen, sodass ein API-Client sie nicht fälschen kann.
Auch der Rest der Ansicht wurde dabei überarbeitet. Die Tabelle passt ohne ausgeblendete Spalten auf einen Laptop-Bildschirm, die Produktspalte ist in die Request-Zeile integriert und das Detailpanel hat Tabs erhalten, sodass Request, Response und Abwehrübersicht jeweils einen eigenen Scrollbereich haben.
Abrechnung: 3D Secure bei Planänderung
Wenn dein Kartenaussteller eine 3DS-Bestätigung für eine Planänderung verlangte (nicht nur beim ersten Abonnieren), wurde dieser Schritt nicht ausgelöst und die Änderung stillschweigend zurückgerollt. Jetzt wird er ausgelöst. Wenn du im letzten Monat versucht hast, den Plan zu wechseln, und nichts passiert zu sein schien, war das der Grund.
Hinter den Kulissen
Der Playground verweigert das Erstellen eines Response-Headers aus Daten einer abgerufenen Seite (eine Header-Injection-Fehlerklasse, die wir früh abgefangen haben). Ein Billing-Endpoint im Dashboard überprüft vor der Antwort, ob der Aufrufer die Ressource besitzt, und schließt so eine IDOR-Lücke.
Die Deploy-Pipeline selbst erhielt nach einem Ausfall am 6., bei dem die Festplatte des Deploy-Hosts mitten im Build vollief, eine ganze Woche lang Korrekturen. Jeder Service verweigert nun den Build ohne Festplatten-Headroom, Deploys laufen sequenziell statt um die Wette, das Gateway bleibt erreichbar, wenn ein Backend instabil ist, und Services beenden sich bei einem SIGTERM tatsächlich, anstatt 30 Sekunden lang zu hängen, bis sie gekillt werden.
Lange Zeit war die Wahl der Browser-Signatur eine Entscheidung, die wir für dich getroffen haben. Das muss nicht so bleiben.