Playwright APIRequestContext mit einer CAPTCHA-Lösung verwenden

1. 1.

   Abhängigkeiten installieren

   Verwende Node.js 22+ und installiere das Paket playwright. Installiere das offizielle JavaScript-SDK aus dem solvethree-Tarball der Version 0.1.0: solvethree-sdk-0.1.0.tgz, verfügbar unter /downloads/ auf solvethree.com. Es wird als @solvethree/sdk importiert; gehe nicht davon aus, dass eine Version in einer Registry verfügbar ist.

2. 2.

   Umgebungsvariablen festlegen

   Stelle dem Node.js-Prozess SOLVETHREE_API_KEY, SOLVETHREE_PROXY und TARGET_URL bereit. Halte den API-Schlüssel des Workspaces auf der Serverseite. TARGET_URL muss der tatsächliche POST-Endpunkt der Anwendung sein, nicht nur die Seite, die das CAPTCHA anzeigt. Verwende eine HTTP- oder HTTPS-Proxy-URL ohne Pfad, Query oder Fragment.

3. 3.

   Website-Profil und Aktion prüfen

   Für den Zielhostnamen muss ein aktives Profil verfügbar sein, auf das dein Workspace zugreifen kann. Richte es vor dem Lösen in der Konsole ein; die Übergabe eines Hostnamens erstellt kein Profil. Das Beispiel verwendet die Aktion login; ändere sie, wenn das Ziel eine andere Aktion erwartet. Die Anfrage verwendet standardmäßig reCAPTCHA Enterprise v3.

Halte die erforderlichen Formularfelder und Sitzungsvoraussetzungen der Anwendung bereit, bevor du das Beispiel ausführst. Es sendet nur das Feld für die CAPTCHA-Antwort. Siehe Website-Profil einrichten, falls der Hostname noch nicht konfiguriert ist.

import { request } from 'playwright';
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const target = new URL(process.env.TARGET_URL);
const proxy = new URL(process.env.SOLVETHREE_PROXY);
const result = await client.solve({ site: target.hostname, action: 'login', proxy: process.env.SOLVETHREE_PROXY });
const proxyConfig = { server: `${proxy.protocol}//${proxy.host}`, username: decodeURIComponent(proxy.username), password: decodeURIComponent(proxy.password) };

const targetClient = await request.newContext({
  proxy: proxyConfig, timeout: 30000,
  extraHTTPHeaders: { 'User-Agent': result.solution.userAgent, 'sec-ch-ua': result.solution.secChUa },
  // storageState: 'your-application-session.json', // only if your flow needs it
});
try {
  const response = await targetClient.post(target.href, {
    form: { 'g-recaptcha-response': result.solution.token }, maxRedirects: 0,
  });
  console.log('Application HTTP status:', response.status());
  // Inspect the response and supply the application's actual fields/CSRF/session.
} finally { await targetClient.dispose(); }

client.solve() erstellt die Aufgabe einmal und fragt ihren Status ab, bis sie bereit ist oder eine Ausnahme ausgelöst wird. Das Beispiel verwendet denselben Proxy zum Lösen und zum Übermitteln. Für Playwright trennt es die Proxyserver-Adresse von den Zugangsdaten und dekodiert Benutzername und Passwort.

Der Anfragekontext setzt solution.userAgent und solution.secChUa als Header. Das Formular sendet solution.token in g-recaptcha-response, nicht die Aufgaben-ID. Verwende den Proxy und die zurückgegebene Identität zusammen; ersetze sie nicht durch andere Browser-Header und sende den Token nicht an ein anderes Ziel.

Ergänze das Formular um die tatsächlichen Felder der Anwendung, einschließlich Zugangsdaten oder CSRF-Daten, sofern erforderlich. Wenn du bereits über die erforderliche Anwendungssitzung verfügst, aktiviere die optionale Einstellung storageState und verweise damit auf den gespeicherten Zustand dieser Sitzung.

APIRequestContext verwaltet einen eigenen Cookie-Speicher. Anfragen über denselben Kontext behalten daher die empfangenen Cookies bei. Cookies werden nicht automatisch mit einem unabhängigen Browserkontext geteilt. Führe vorbereitende Sitzungsanfragen und den abschließenden POST im selben Kontext aus, wenn sie Cookies gemeinsam verwenden müssen. Der finally-Block gibt den Kontext frei, sobald die Übermittlung abgeschlossen ist.

Das Beispiel protokolliert den HTTP-Status der Anwendung; es bestätigt nicht, dass die Anmeldung erfolgreich war. Wenn maxRedirects auf null gesetzt ist, siehst du die ursprüngliche Antwort, statt einer Weiterleitung zu folgen. Vergleiche ihren Body, ihre Header und Cookies mit der erwarteten Erfolgsantwort der Anwendung. Eine Weiterleitung oder HTTP 200 allein sagt möglicherweise nicht aus, ob der Vorgang erfolgreich war.

Die Aufgabe ist bereit, aber die Anwendung lehnt den POST ab.

Prüfe zuerst die ausgehende Anfrage: Token-Feld, Hostname und Aktion, Proxy, zurückgegebene Identität, erforderliche Formularfelder, CSRF-Wert und Sitzungscookies.

Probiere Folgendes: Korrigiere fehlende oder nicht übereinstimmende Anfragedaten, bevor du für einen weiteren Lösungsversuch bezahlst. Eine bereite Aufgabe liefert eine verwendbare Lösung, garantiert aber nicht, dass die nachgelagerte Anwendung sie akzeptiert.

Der Lösungsversuch endet mit einer fehlgeschlagenen Aufgabe.

Lies errorCode und error; behandle nicht jeden Fehler als Guthabenproblem.

Probiere Folgendes: Beende die Statusabfragen für diese Aufgabe und behebe die gemeldete Ursache. Fehlgeschlagene Lösungsversuche werden erstattet. Hinweise zur Einordnung von Fehlern findest du unter API-Fehlerbehandlung.

Bei der Aufgabenerstellung tritt eine Zeitüberschreitung auf oder die Verbindung bricht ab.

Prüfe, ob du eine Aufgaben-ID hast oder eine requestId verwendet hast. Eine Verbindungszeitüberschreitung beweist nicht, dass die Erstellung fehlgeschlagen ist.

Probiere Folgendes: Rufe die vorhandene Aufgabe ab, wenn du ihre ID hast. Damit Erstellungsanfragen nach einem Verbindungsproblem wiederaufgenommen werden können, gib eine requestId an und verwende sie mit exakt denselben Eingaben erneut; dadurch wird die vorhandene Aufgabe zurückgegeben. Starte nicht sofort einen weiteren eigenständigen Lösungsversuch.

Die Anfrage an die Anwendung gibt einen HTTP-Fehler zurück.

Prüfe die Antwort des Ziels getrennt vom Ergebnis der solvethree-Aufgabe.

Probiere Folgendes: Behandle die nicht erfolgreiche Antwort, bevor du ihren Body als Erfolgsdaten verarbeitest. Korrigiere die Anfrage an die Anwendung oder behebe den gemeldeten Serverfehler, statt davon auszugehen, dass der Token die Ursache ist.