Highlights
Viele Websites zeigen ihre Startseite jedem, sperren aber alles, was einen Klick tiefer liegt. Auto geht jetzt durch den Vordereingang: Es übernimmt die Session, die diese Einstiegsseite vergibt, und fordert die gewünschte Seite direkt damit an. Browser hat diese Woche die größeren Aufgaben übernommen. Es löst die Checkbox-Prüfung einer Website auch dann, wenn mehrere Requests dieselbe Seite gleichzeitig anfragen, und meldet bei einer weiterhin blockierten Seite detailliert, was es gesehen hat, statt nur ein einziges Wort zurückzugeben.
What's New
Auto öffnet Seiten mit Session-Gate
Ein eBay-Angebot verweigert bei jedem unserer Wege einen Cold Request. Dieselbe URL öffnet sich, sobald der Request das Cookie Jar mitsendet, das die Startseite von eBay jedem Besucher ausstellt. Kein Login, kein fremder Account, nichts, was du nicht auch manuell in einem Tab machen könntest.
Auto übernimmt das jetzt für dich. Wenn ein Exit den Origin erreicht, die Unterseite aber dennoch verweigert wird, ruft Auto die Root-URL der Website über denselben Exit ab, speichert die empfangenen Cookies und versucht es erneut. Die Response zeigt dir, was passiert ist: Der erfolgreiche Schritt meldet warmup.
Interessant sind vor allem die Kosten. Diese Session ist portabel, das Jar ist also nicht an den Exit gebunden, über den es erstellt wurde. Folgende Lesezugriffe laufen per Replay über /api/proxy und treffen für 2 Credits auf /api/single. Das ist dieselbe Escalate-then-Replay-Kette, über die wir beim Thema Cloudflare Clearance geschrieben haben, wobei die Session-Cookies des Anbieters den Platz von cf_clearance einnehmen.
Gezielt begrenzt: maximal zwei Versuche pro Request auf unterschiedlichen Exits, nur nachdem die tiefe URL bereits fehlgeschlagen ist und nur, wenn der Exit den Origin überhaupt erreichen konnte. Eine Website, die uns einfach blockiert, verursacht also einmalig zwei zusätzliche Sub-Calls statt einer Endlosschleife. Mehr Details dazu, wie die Ladder ihre Schritte wählt, findest du im Auto-Artikel.
Browser löst Checkbox-Challenges bei überlappenden Requests
Browser löst die Checkbox-Prüfung jetzt auch bei parallelen Requests auf dieselbe Seite. Drei gleichzeitige Zugriffe auf eine News-Website hinter Turnstile: 5,2 s, 5,8 s, 9,1 s.
Zwei kleinere Änderungen kamen hinzu. Ein Klick zählt erst, wenn das Widget tatsächlich verschwunden ist, da Cloudflare Challenges häufiger neu ausgibt, als man erwarten würde (der erste Klick beendet den Vorgang oft noch nicht). Zudem meldet eine erfolgreich gelöste Seite defenseSolved: true bei dem Call, der sie freigeschaltet hat. Das ist derselbe Call, der für den Solve abgerechnet wird.
Eine blockierte Seite meldet, was der Solver gesehen hat
"Timeout" lässt Latenzprobleme vermuten. Meist liegt es nicht an der Latenz und die Lösung ist nur einen Exit entfernt.
Lehnt der Prüfdienst einen Versuch ab, startet er die Prüfung neu und hinterlegt einen eigenen Retry-Marker im Jar. Browser liest diesen Marker aus. Statt das Timeout abzuwarten, antwortet es nach rund 17 Sekunden mit dem Namen des Anbieters, den ausgeführten Klicks und der Information, ob Clearance erteilt wurde:
Timeout after 12s: the cloudflare challenge did not complete from this exit
(2 checkbox presses, clearance granted, challenge re-issued by the site)
Eine dieser Zeilen sagt dir, dass du den Request anders senden sollst. Die andere sagt dir gar nichts.
Fehler aus dem API-Layer sind jetzt ebenfalls verständlicher. Ein Request, der das Zeitlimit überschreitet, liefert einen Timeout. Ein nicht erreichbarer Dienst meldet sich als nicht verfügbar. Keiner von beiden wird als Proxy-Problem deklariert, wenn der Request überhaupt keinen Proxy verwendet hat. timeout_ms bei einem Browser-Aufruf wird bis zu den vollen 120 Sekunden berücksichtigt, die die API akzeptiert. Ein langsames Ziel erhält also genau das von dir festgelegte Budget, und du siehst das tatsächliche Ergebnis der Engine statt das des Gateways. Die Parameter findest du in der API-Referenz.
Rechnungsdetails und Korrekturen im Ausstellungsmonat
Bulgarische Rechnungen weisen einen Unternehmensvertreter (MOL) im Empfängerfeld aus. Bisher hat das System diesen Wert nicht erfasst, weshalb die Zeile immer leer blieb. Das Feld ist jetzt in den Rechnungsdetails verfügbar.
Die Rechnungstabelle bietet zudem die Option "Details aktualisieren" für Rechnungen, die sich noch im Ausstellungsmonat befinden und deren gespeicherte Daten vom aktuellen Rechnungsprofil abweichen. Der Dialog zeigt jedes geänderte Feld mit dem neuen Wert an und stellt klar, dass Rechnungsnummer, Daten und Beträge unverändert bleiben. Die Bestätigung gilt als deine Zustimmung und wird bei uns protokolliert. Liegen innerhalb des Zeitfensters keine Änderungen vor, zeigt die Rechnung "Bearbeitbar bis" mit dem entsprechenden Datum an. So siehst du das Zeitfenster direkt, statt es erst im Nachhinein zu bemerken.
Unter der Haube
Jedes Skript im Dashboard wird von unserem eigenen Origin ausgeliefert. Nach dem Login wirst du ausschließlich auf Pfade dieser Website weitergeleitet.
Rollouts des Rendering-Dienstes erfolgen Server für Server. Jeder Server muss erfolgreich eine echte Seite ausliefern, bevor der nächste aktualisiert wird.
Im Statusportal liefert der Issues-Endpoint offene und behobene Vorfälle über die öffentliche API aus, identisch zur Anzeige auf der Seite.
Eine klare Ablehnung kostet dich einen einzigen Call. Ein Warten, das in einem "Timeout" endet, zwingt zum Rätseln über den nächsten Schritt, kostet aber genau das Gleiche. Fehler sind Teil des Produkts. Seit dieser Woche behandeln wir sie auch so.