Sammlung von Patches für Puppeteer und Playwright, um Automatisierungserkennung und Lecks zu vermeiden. Hilft, Cloudflare- und DataDome-CAPTCHA-Seiten zu umgehen. Einfach zu patchen/entpatchen, kann bei Bedarf aktiviert/deaktiviert werden.
Dieses Repository enthält Patches zur Verbesserung beliebter Web-Automatisierungsbibliotheken. Konkret richtet es sich an die Pakete puppeteer und playwright.
Einige Aspekte von Automatisierungsbibliotheken oder des Browserverhaltens lassen sich nicht über Einstellungen oder Befehlszeilenoptionen anpassen. Daher beheben wir diese Probleme, indem wir den Quellcode der Bibliothek patchen. Dieser Ansatz ist zwar fragil und kann brechen, wenn sich der Quellcode der Bibliotheken im Laufe der Zeit ändert, aber das Ziel ist es, dieses Repository mit Hilfe der Community zu pflegen, um die Patches aktuell zu halten.
Von Haus aus bringen Puppeteer und Playwright einige erhebliche Leaks mit, die leicht zu erkennen sind. Egal wie gut deine Proxys, Fingerprints und Verhaltensskripte sind – wenn du es nicht gepatcht hast, bist du für jede große Website nur eine große rote Flagge.
🕵️ Du kannst dein Automatisierungs-Setup mit rebrowser-bot-detector ganz einfach auf gängige moderne Erkennungen testen (Quellen und Details)
| Vor den Patches 👎 | Nach den Patches 👍 |
|---|---|
 |  |
Wenn du dich nicht mit den Patches und allen möglichen Fehlern herumschlagen willst, gibt es eine Drop-in-Lösung für dich. Diese Pakete haben einfach rebrowser-patches auf den ursprünglichen Code angewendet, nichts weiter.
Puppeteer: rebrowser-puppeteer (src) und rebrowser-puppeteer-core (src)
Playwright (Node.js): rebrowser-playwright (src) und rebrowser-playwright-core (src)
Playwright (Python): rebrowser-playwright (src)
Der einfachste Weg, es zu nutzen, ist, deine package.json anzupassen, sodass du neue Pakete verwendest, aber den alten Namen als Alias behältst. So musst du keinen Quellcode deiner Automatisierung ändern. So geht's:
package.json und ersetze "puppeteer": "^23.3.1" und "puppeteer-core": "^23.3.1" durch "puppeteer": "npm:rebrowser-puppeteer@^23.3.1" und "puppeteer-core": "npm:rebrowser-puppeteer-core@^23.3.1". Hinweis: 23.3.1 ist nur ein Beispiel – prüfe die neueste Version auf npm.npm install aus (oder yarn install)Eine andere Möglichkeit ist, tatsächlich die neuen Pakete anstelle der ursprünglichen zu verwenden. Folge dazu diesen Schritten:
package.json und ersetze die Pakete puppeteer und puppeteer-core durch rebrowser-puppeteer und rebrowser-puppeteer-core. Ändere nicht die Versionen der Pakete, ersetze nur die Namen.npm install aus (oder yarn install)puppeteer und puppeteer-core und ersetze sie durch rebrowser-puppeteer und rebrowser-puppeteer-core🚀 Das war's! Besuche einfach die Seite rebrowser-bot-detector und teste deinen gepatchten Browser.
Unser Ziel ist es, diese Drop-in-Ersatzpakete mit den neuesten Versionen zu pflegen und zu unterstützen, aber wir konzentrieren uns hauptsächlich auf frische Versionen. Wenn du also immer noch puppeteer 13.3.7 aus den frühen 90ern verwendest, könnte es an der Zeit sein, zu aktualisieren. Die Wahrscheinlichkeit ist hoch, dass dabei nichts kaputtgeht, da die API im Laufe der Zeit recht stabil ist.
Runtime.Enable-Leak behebenBeliebte Automatisierungsbibliotheken verlassen sich auf den CDP-Befehl Runtime.Enable, der den Empfang von Ereignissen aus der Domäne Runtime. ermöglicht. Dies ist entscheidend für die Verwaltung von Ausführungskontexten, die zum Ausführen von JavaScript auf Seiten verwendet werden – eine Schlüsselfunktion für jeden Automatisierungsprozess.
Es gibt jedoch eine Technik, die die Verwendung dieses Befehls erkennt und aufdeckt, dass der Browser von Automatisierungssoftware wie Puppeteer oder Playwright gesteuert wird. Diese Technik wird von allen großen Anti-Bot-Systemen wie Cloudflare, DataDome und anderen eingesetzt.
Wir haben einen ausführlichen Artikel über unsere Untersuchung zu diesem Leak vorbereitet, den du in unserem Blog lesen kannst.
Weitere Details zu dieser Technik findest du im Blogbeitrag von DataDome: How New Headless Chrome & the CDP Signal Are Impacting Bot Detection.
Kurz gesagt: Es handelt sich um ein paar Zeilen JavaScript auf der Seite, die automatisch aufgerufen werden, wenn Runtime.Enable verwendet wurde.
Unser Fix deaktiviert den automatischen Runtime.Enable-Befehl in jedem Frame. Stattdessen erstellen wir manuell Kontexte mit unbekannten IDs, wenn ein Frame erstellt wird. Wenn dann Code ausgeführt werden muss, gibt es mehrere Möglichkeiten, die Kontext-ID zu erhalten.
🟢 Vorteile: Der ultimative Ansatz, der den Zugriff auf die Hauptwelt beibehält und mit Web Workern und Iframes funktioniert. Du musst nichts an deiner bestehenden Codebase ändern.
🔴 Nachteile: Bisher wurden keine entdeckt.
Page.createIsolatedWorld erstellen und seine ID speichern.🟢 Vorteile: Dein gesamter Code wird in einer separaten isolierten Welt ausgeführt, wodurch verhindert wird, dass Seiten-Skripte deine Änderungen über MutationObserver und andere Techniken erkennen.
🔴 Nachteile: Du kannst nicht auf Variablen und Code des Hauptkontexts zugreifen. Während dies für einige Anwendungsfälle notwendig ist, funktioniert der isolierte Kontext für die meisten Szenarien in der Regel einwandfrei. Außerdem erlauben Web Worker nicht das Erstellen neuer Welten, sodass du deinen Code nicht in einem Worker ausführen kannst. Das ist ein Nischen-Anwendungsfall, kann aber in manchen Situationen relevant sein. Es gibt einen Workaround für dieses Problem – lies dazu bitte How to Access Main Context Objects from Isolated Context in Puppeteer & Playwright.
Runtime.Enable aufrufen und dann sofort Runtime.Disable aufrufen.Dies löst Runtime.executionContextCreated-Ereignisse aus, sodass wir die richtige Kontext-ID abfangen können.