Eine CapSolver-reCAPTCHA-Integration auf solvethree umstellen

solvethree verwendet standardmäßig reCAPTCHA v3 Enterprise und akzeptiert auch Standard-v3. Die anderen öffentlich verfügbaren Produkte sind Kasada und Ticketmaster TMPT. reCAPTCHA v2, hCaptcha, Turnstile und das Lösen per Browsererweiterung werden nicht unterstützt. Daher ist dies kein universeller Ersatz für jede CapSolver-Integration.

Richten Sie vor dem Senden einer reCAPTCHA-Aufgabe die Zielwebsite in der Konsole ein und stellen Sie sicher, dass Ihrem Workspace ein aktives Profil zur Verfügung steht. Das Senden eines Hostnamens und einer Aktion erstellt dieses Profil nicht. Entfernen Sie nicht einfach das CapSolver-Feld websiteKey in der Annahme, dass die verbleibende Anfrage ausreicht.

Die ursprüngliche Anfrage verwendet clientKey von CapSolver und eine anbieterspezifische Aufgabenhülle:

{
  "clientKey": "CAPSOLVER_API_KEY",
  "task": {
    "type": "ReCaptchaV3Task",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "pageAction": "login",
    "isEnterprise": true,
    "proxy": "http://user:[email protected]:8080"
  }
}

Senden Sie für solvethree den folgenden flachen Anfragetext an POST https://api.solvethree.com/v1/tasks. Setzen Sie den Authorization-Header auf Bearer gefolgt vom API-Schlüssel Ihres Workspace. Bewahren Sie diesen Schlüssel auf dem Server auf; übernehmen Sie clientKey nicht in den neuen JSON-Anfragetext.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

Das Beispiel ist eine Enterprise-Anfrage, weil es den Standardwert von recaptchaType beibehält. Wählen Sie Standard-v3 explizit aus, wenn Ihr Ziel dies verwendet; ordnen Sie nicht jeden CapSolver-Aufgabentyp dem Enterprise-Standard zu.

Für eine CapSolver-ProxyLess-Aufgabe gibt es hier keine direkte Entsprechung ohne Proxy: solvethree erfordert eine vom Aufrufer bereitgestellte Proxy-Eingabe. Wenn Ihre aktuelle Integration keinen Proxy verwaltet, ist dies eine Integrationsänderung, keine Feldumbenennung. Kopieren Sie auch keine SOCKS-Proxy-Konfiguration in die neue Anfrage; solvethree akzeptiert HTTP- und HTTPS-Proxy-URLs.

Beginnen Sie mit einem einzelnen Proxy, damit die für Lösung und Übermittlung verwendete Route eindeutig ist. Wenn Sie stattdessen proxyCandidates verwenden, geben Sie höchstens zwölf unterschiedliche HTTP- oder HTTPS-Proxy-URLs ohne Pfade, Abfragen oder Fragmente an. Mit Kandidaten kann der Dienst alternative Ausgangsverbindungen versuchen; sie garantieren nicht, dass ein Proxy oder Ziel funktioniert.

CapSolver ruft asynchrone Ergebnisse über getTaskResult mit clientKey und taskId ab. solvethree ruft sie über Bearer-authentifiziertes GET /v1/tasks/:id ab. Aktualisieren Sie sowohl den Ergebnisparser als auch den HTTP-Aufruf; die Status- und Fehlerfelder von CapSolver folgen einem anderen API-Vertrag.

1. 1.

   Zuerst die HTTP-Antwort prüfen

   Behandeln Sie nicht erfolgreiche HTTP-Antworten, bevor Sie die Nutzdaten einer erfolgreichen Antwort lesen. Ein HTTP-Anfragefehler und eine fehlgeschlagene Lösungsaufgabe müssen getrennt behandelt werden.

2. 2.

   Die bei der Erstellung zurückgegebene Aufgabe prüfen

   Die reCAPTCHA-Erstellung wartet standardmäßig bis zu 15 Sekunden, sodass die Antwort bereits einen Endstatus enthalten kann. Nur ready enthält eine nutzbare Lösung. Wenn die Aufgabe pending oder solving ist, rufen Sie sie über ihre zurückgegebene solvethree-Aufgaben-ID ab.

3. 3.

   Polling bei ready oder failed beenden

   Übergeben Sie bei ready die Lösung an Ihren Übermittlungscode. Prüfen Sie bei failed die Felder errorCode und error und beenden Sie das Polling für diese Aufgabe. Fehlgeschlagene Lösungsversuche werden erstattet. Wiederholen Sie nicht blind unveränderte ungültige Eingaben und nehmen Sie nicht an, dass jeder Fehler unzureichendes Guthaben bedeutet.

Kennzeichnen Sie bei einer schrittweisen Migration jede Aufgaben-ID mit ihrem Anbieter. Schließen Sie bestehende CapSolver-Aufgaben über CapSolver ab und leiten Sie neue solvethree-Aufgaben über solvethree. Vereinheitlichen Sie deren Ergebnisse in Ihrem Adapter, statt die Aufgaben-ID des alten Anbieters an die neue API zu senden.

Verwenden Sie solution.token, wenn Sie das reCAPTCHA-Ergebnis an das vorgesehene Ziel übermitteln. Behalten Sie auch die zurückgegebenen Werte userAgent und secChUa bei und verwenden Sie den erfolgreichen Proxy für die Übermittlung. Wenn Ihr bestehender Adapter nur eine Token-Zeichenfolge zurückgibt, ändern Sie ihn so, dass diese Informationen bis zum übermittelnden Client weitergereicht werden.

Wenn ein fertiges Token abgelehnt wird, prüfen Sie die ausgehende Anwendungsanfrage, bevor Sie für einen weiteren Lösungsversuch bezahlen. Prüfen Sie, ob sie das neue Token enthält – keine Aufgaben-ID und kein altes Token – und ob die Übermittlung die zurückgegebene Browseridentität, den erfolgreichen Proxy und die vorgesehene Ziel-URL verwendet. Eine Aufgabe mit dem Status ready bedeutet, dass eine Lösung generiert wurde, nicht, dass das Ziel Ihre nachfolgende Anfrage akzeptiert hat.

Das Beispiel nach der Migration enthält requestId zur Wiederherstellung. Generieren Sie für jede neue logische Aufgabe einen Wert und speichern Sie ihn zusammen mit den exakten Anfrageeingaben. Er muss 1–64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche enthalten. Bei Wiederverwendung mit derselben Aufgabenanfrage wird die bestehende Aufgabe zurückgegeben; die Verwendung mit anderen Eingaben führt zu einem Konflikt.

Wenn die Erstellung das Zeitlimit überschreitet, rufen Sie die Aufgabe ab, sofern Sie ihre ID haben, oder senden Sie denselben Anfragetext mit derselben requestId erneut. Eine verlorene Antwort beweist nicht, dass die Erstellung fehlgeschlagen ist. Generieren Sie keine neue ID, nur weil Ihr Client nicht mehr gewartet hat.

Berücksichtigen Sie im Zeitlimit Ihres Clients die standardmäßige Wartezeit bei der reCAPTCHA-Erstellung von bis zu 15 Sekunden zuzüglich Netzwerk-Overhead. GET-Polling antwortet standardmäßig ohne Wartezeit und akzeptiert waitMs bis zu 15000. Setzen Sie waitMs in die URL-Abfrage, nicht in das Aufgaben-JSON, und berücksichtigen Sie diese Wartezeit auch im Polling-Zeitlimit.