Die CAPTCHA-API mit HTTPie testen

• Installieren Sie HTTPie und jq und führen Sie das Beispiel in Bash aus. Diese Befehle verwenden die ausführbare Datei http von HTTPie, nicht curl oder einen Shell-Alias für curl.
• Setzen Sie die Umgebungsvariable SOLVETHREE_API_KEY auf den API-Schlüssel Ihres Workspaces. Führen Sie dies auf einem vertrauenswürdigen Rechner aus; halten Sie den Schlüssel aus Browsercode fern.
• Konfigurieren Sie in der Konsole ein aktives Profil für Ihren Zielhostnamen. Das Senden eines Hostnamens und einer Aktion erstellt kein Profil. Siehe Website-Profil einrichten.
• Ersetzen Sie den Beispielhostnamen, die Aktion und die Proxy-URL. Verwenden Sie eine HTTP- oder HTTPS-Proxy-URL ohne Pfad, Abfrage oder Fragment.
• Ersetzen Sie den requestId-Platzhalter durch eine eindeutige ID für diesen logischen Task: 1–64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche. Speichern Sie sie vor dem Senden der Anfrage.

Die Anfrage ist für reCAPTCHA Enterprise bestimmt: recaptchaType hat standardmäßig den Wert enterprise-v3. Sie benötigt site, action und genau eines der Felder proxy oder proxyCandidates; dieses Beispiel verwendet einen Proxy. Fügen Sie keine Felder namens type oder url hinzu.

set -eu
umask 077
# Install HTTPie and jq. Keep the same request.json for recovery.
cat > request.json <<'JSON'
{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://USER:PASSWORD@PROXY:PORT",
  "requestId": "replace-with-one-unique-logical-task-id"
}
JSON
# This file contains proxy credentials; keep it private.
http --check-status --timeout=30 POST https://api.solvethree.com/v1/tasks \
  Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==0 < request.json > task.json
TASK_ID=$(jq -r '.id' task.json)
http --check-status --timeout=30 GET "https://api.solvethree.com/v1/tasks/$TASK_ID" \
  Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==15000
# pending/solving: retrieve the same ID again, within a finite deadline.
# ready: use solution. failed: stop and inspect errorCode/error.
# A timed-out POST is recovered with the unchanged file and requestId.

Die JSON-Zeichenfolgen in Anführungszeichen werden in request.json geschrieben, das HTTPie über stdin einliest. Der Authorization-Header sendet Ihren Schlüssel mit Bearer-Authentifizierung. Halten Sie request.json privat, da die Datei Proxy-Zugangsdaten enthält.

waitMs==0 und waitMs==15000 sind HTTPie-Abfrageparameter, keine Felder im JSON-Body. Der POST fordert keine Wartezeit an; der GET verwendet eine Wartezeit von 15,000 ms. Die separate HTTPie-Option --timeout=30 setzt ein clientseitiges Zeitlimit von 30 Sekunden.

Die POST-Antwort wird in task.json gespeichert, und jq extrahiert daraus die id für den GET. Führen Sie die Befehle der Reihe nach aus. set -eu stoppt das Skript, wenn HTTPie einen Fehler meldet, bevor eine unvollständige Antwort für den Abruf verwendet werden kann.

--check-status erkennt nicht erfolgreiche HTTP-Antworten. Behandeln Sie diese, bevor Sie den Body als erfolgreiche Task-Antwort verarbeiten. Eine erfolgreiche HTTP-Anfrage kann dennoch einen unfertigen oder fehlgeschlagenen Task zurückgeben; lesen Sie daher als Nächstes das JSON-Feld status.

Das Beispiel führt einen einzelnen Abruf aus, keine Polling-Schleife. Wenn Sie eine fertige Lösung an das vorgesehene Ziel übermitteln, verwenden Sie die zurückgegebenen Werte userAgent und secChUa mit dem erfolgreichen Proxy. Bereit bedeutet, dass solvethree eine Lösung generiert hat – nicht, dass Ihre Anwendungsanfrage erfolgreich war.

Eine clientseitige Zeitüberschreitung beweist nicht, dass die Task-Erstellung fehlgeschlagen ist. Wenn Sie die Task-ID bereits haben, rufen Sie den Task ab. Falls der POST das Zeitlimit überschritten hat, bevor Sie eine ID erhalten haben, führen Sie ihn mit der unveränderten request.json einschließlich der ursprünglichen requestId erneut aus. Dieselbe ID und dieselben Task-Eingaben geben den vorhandenen Task zurück.

Extrahieren Sie keine ID aus einer leeren oder unvollständigen task.json; stellen Sie zuerst den POST wieder her. Ändern Sie weder Proxy noch Aktion oder andere Task-Eingaben, wenn Sie diese requestId wiederverwenden – unterschiedliche Eingaben verursachen einen Konflikt. Verwenden Sie eine neue requestId nur, wenn Sie einen neuen logischen Task erstellen möchten.