Ein gelöstes Token in einer Playwright-JSON-Anfrage übermitteln

1. 1.

   Lösungsdienst vorbereiten

   Verwenden Sie Node.js 22+, Playwright und das offizielle JavaScript SDK. Folgen Sie der SDK-Installationsanleitung; nutzen Sie den dokumentierten Paketdownload, statt die Verfügbarkeit in der npm-Registry vorauszusetzen. Belassen Sie SOLVETHREE_API_KEY im Node.js-Prozess, nicht im Browsercode.

2. 2.

   Website und Proxy konfigurieren

   Setzen Sie TARGET_URL auf Ihre eigene Testseite und SOLVETHREE_PROXY auf die URL ihres HTTP- oder HTTPS-Proxys. Das Beispiel fordert die Aktion login für den Hostnamen der Seite an. Dieser Hostname benötigt ein aktives Workspace-Profil; konfigurieren Sie zuerst das Website-Profil. Ändern Sie die Aktion, wenn Ihre Anwendung eine andere verwendet.

3. 3.

   Den genauen Absendevorgang bestimmen

   Setzen Sie TARGET_SUBMIT_URL auf den JSON-POST-Endpunkt einschließlich Pfad. Er muss denselben Origin wie die Seite haben. Das Beispiel erwartet ein Objekt mit recaptchaToken und eine Schaltfläche, deren zugänglicher Name exakt Submit lautet. Ändern Sie diese anwendungsspezifischen Angaben gemeinsam.

Verwenden Sie als Test-Fixture eine Seite, die ein JSON-Objekt an diesen Endpunkt sendet und eine prüfbare Antwort zurückgibt. Fügen Sie ein weiteres Feld und ein CSRF-Feld hinzu, damit Sie prüfen können, dass beide unverändert bleiben. Eine lokale Fixture, die nur die Anfrage zurückgibt, kann das Umschreiben des JSON demonstrieren, überprüft aber nicht die CAPTCHA-Akzeptanz. Das bereitgestellte Beispiel führt weiterhin eine echte Lösung durch und benötigt eine konfigurierte Website, die über den Proxy erreichbar ist.

import { chromium } 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 submit = new URL(process.env.TARGET_SUBMIT_URL);
if (submit.origin !== target.origin) throw new Error('Use this demo with a same-origin submission URL');
const browser = await chromium.launch();
try {
  const context = await browser.newContext({ proxy: proxyConfig, userAgent: result.solution.userAgent,
    extraHTTPHeaders: { 'sec-ch-ua': result.solution.secChUa } });
  const page = await context.newPage();
  await page.route(submit.href, async route => {
    if (route.request().method() !== 'POST') return route.continue();
    const body = route.request().postDataJSON();
    if (!body || typeof body !== 'object' || Array.isArray(body)) throw new Error('Expected the known JSON object');
    await route.continue({ postData: JSON.stringify({ ...body, recaptchaToken: result.solution.token }),
      headers: { ...route.request().headers(), 'content-type': 'application/json' } });
  });
  await page.goto(target.href);
  const outcome = page.waitForResponse(r => r.url() === submit.href && r.request().method() === 'POST');
  await page.getByRole('button', { name: 'Submit', exact: true }).click();
  console.log('Application HTTP status:', (await outcome).status());
  // recaptchaToken, the Submit button and this endpoint belong to this demo app.
  // Adapt them to the real application, retaining its session/CSRF data.
  await context.close();
} finally { await browser.close(); }

client.solve erstellt die Aufgabe und fragt ihren Status ab, bis sie bereit ist, oder löst eine Ausnahme aus. Anschließend erstellt das Beispiel einen Browserkontext mit solution.userAgent, solution.secChUa und demselben einzelnen Proxy, der für die Lösung angegeben wurde. Das SDK wendet die Lösung nicht auf den Browser an; das übernimmt der Routen-Handler.

Der Browserkontext ist neu. Falls das Absenden eine Authentifizierung oder eine andere Sitzungseinrichtung erfordert, führen Sie diese vor dem Absenden in diesem Kontext durch. Das Beispiel importiert keine bestehende Browsersitzung.

Die Route wird vor der Navigation registriert und auf die konfigurierte Absende-URL beschränkt. Anfragen mit einer anderen Methode als POST werden unverändert weitergeleitet. Bei einem POST liest der Handler das vorhandene JSON-Objekt, kopiert dessen Felder und ersetzt nur recaptchaToken.

Dadurch bleiben Felder im Anfragebody wie Formularwerte und CSRF-Daten erhalten. Der Handler kopiert außerdem die Anfrageheader und setzt den Inhaltstyp auf JSON. Behalten Sie das bestehende Sitzungs- und CSRF-Verhalten der Anwendung bei; ein gelöstes Token ersetzt keines von beiden.

Weiten Sie die Route nicht auf alle Anfragen aus und ersetzen Sie nicht irgendein Feld, das zufällig wie ein Token aussieht. Prüfen Sie die ausgehende Anfrage Ihrer eigenen Anwendung und verwenden Sie den tatsächlichen Feldnamen. Dieses Beispiel erkennt keine Widgets, ruft keine beliebigen Callbacks auf und unterstützt keine beliebigen Drittanbieterseiten. Die Netzwerkdokumentation von Playwright beschreibt den Mechanismus zum Abfangen.

Das Warten auf die Antwort beginnt vor dem Klick und gleicht die Absende-URL und die POST-Methode ab. Der protokollierte Status gehört zur Antwort der Anwendung – nicht zur solvethree-Aufgabe. Prüfen Sie den Body dieser Antwort oder den resultierenden Anwendungszustand anhand der Erfolgskriterien der Anwendung. Weder eine bereite Aufgabe noch ein HTTP-Erfolgsstatus allein beweist, dass die Anwendung das Token akzeptiert hat.

Das Warten auf die Antwort endet nicht.

Prüfen Sie, ob genau die Schaltfläche Submit einen POST an die konfigurierte URL auslöst.

Probiere Folgendes: Passen Sie den Schaltflächen-Locator, den Endpunkt oder die Methode an die Anwendung an. Weiten Sie das Abfangen nicht auf unbeteiligten Datenverkehr aus.

Die Route kann kein JSON-Objekt lesen.

Prüfen Sie den Anfragebody und den Inhaltstyp.

Probiere Folgendes: Verwenden Sie diesen Handler nur für den bekannten Endpunkt für JSON-Objekte. Formulardaten, Arrays und andere Nutzdatenformate erfordern eine andere Verarbeitung.

Die Aufgabe ist bereit, aber die Anwendung lehnt die Übermittlung ab.

Prüfen Sie das ausgehende JSON auf solution.token und kontrollieren Sie anschließend Sitzungs-/CSRF-Daten, Aktion, zurückgegebene Browseridentität und Proxy.

Probiere Folgendes: Korrigieren Sie die nicht passende Anfrage, bevor Sie für eine weitere Lösung bezahlen. Lassen Sie den Browser auf dem für die Lösung verwendeten Proxy und verwenden Sie die zurückgegebene Identität.

Die Lösung schlägt fehl, bevor der Browser geöffnet wird.

Unterscheiden Sie zwischen einem HTTP-Anfragefehler und einem endgültigen Aufgabenfehler. Prüfen Sie bei einer fehlgeschlagenen Aufgabe errorCode und error.

Probiere Folgendes: Beheben Sie das gemeldete Eingabe-, Profil- oder Verbindungsproblem, statt es mit unveränderten Eingaben erneut zu versuchen. Siehe API-Fehlerbehandlung.