Die CAPTCHA-Aufgaben-API in Make verwenden

Richten Sie zunächst in Ihrem Workspace ein aktives Profil für den Zielhostnamen ein. Das Senden von site und action erstellt kein Profil. Siehe Websiteprofil einrichten, wenn das Ziel noch nicht konfiguriert ist.

1. 1.

   HTTP-v4-Authentifizierung konfigurieren

   Wählen Sie als Authentifizierungstyp API key und erstellen Sie einen Schlüsselbund für Zugangsdaten. Setzen Sie den Schlüssel auf Bearer, gefolgt von einem Leerzeichen und Ihrem Workspace-API-Schlüssel, die Platzierung auf In the header und den Parameternamen auf Authorization. Beschränken Sie die zulässigen Dienstursprünge auf https://api.solvethree.com. Bewahren Sie den Schlüssel im Schlüsselbund auf, statt ihn über Szenariodaten weiterzugeben.

2. 2.

   Anfrageeinstellungen eingeben

   Verwenden Sie die unten gezeigte Methode, URL, Abfrageparameter, Header und den JSON-Body. Tragen Sie jede Angabe in das entsprechende Modulfeld ein. Nur der Inhalt von body gehört in den JSON-Anfrageinhalt; das vollständige Beispiel dient zur Erläuterung der Konfiguration und ist kein importierbarer Make-Blueprint.

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• Ersetzen Sie site durch den konfigurierten Hostnamen, nicht durch eine vollständige URL. Setzen Sie action auf die Aktion, die der Zielablauf verwendet.
• Ersetzen Sie proxy durch Ihre Proxy-URL. Die Anfrage erfordert genau eines der Felder proxy oder proxyCandidates; das Beispiel verwendet einen einzelnen Proxy.
• Geben Sie jedem neuen logischen Auftrag eine eigene requestId und bewahren Sie diese zur Wiederherstellung auf. Der Beispielwert ist ein Platzhalter, keine ID, die Sie für voneinander unabhängige Aufträge wiederverwenden sollten.
• Fügen Sie dieser reCAPTCHA-Anfrage weder type noch url hinzu. Wenn recaptchaType weggelassen wird, gilt der Standardwert enterprise-v3.

Speichern Sie nach einer erfolgreichen Erstellungsantwort die zurückgegebene Aufgaben-ID beim logischen Auftrag, bevor Sie weitere Schritte ausführen. Fügen Sie ein separates HTTP-Anfragemodul hinzu, um diese Aufgabe abzurufen.

Behandeln Sie nicht erfolgreiche HTTP-Antworten, bevor Sie anhand des Aufgabenstatus weiterleiten. Ein HTTP-Fehler ist nicht dasselbe wie eine Aufgabe mit dem Status failed; behandeln Sie eine nicht lesbare oder nicht erfolgreiche Antwort nicht als weiteres pending-Ergebnis.

Fügen Sie nach einem erfolgreichen GET einen Router mit expliziten Filtern für den zurückgegebenen status hinzu. Leiten Sie nicht jede erfolgreiche HTTP-Antwort auf die Lösungsroute weiter.

Definieren Sie den Filter für nicht abgeschlossene Aufgaben explizit, statt ihn als Auffangroute zu verwenden. Ein fehlender oder unerwarteter Status sollte geprüft werden, statt stillschweigend endloses Polling auszulösen. Untersuchen Sie auf der Fehlerroute den gemeldeten Fehler, bevor Sie eine weitere Aufgabe erstellen; unveränderte ungültige Eingaben werden durch Wiederholungen nicht besser.

Ein einfacher, begrenzter Ablauf führt pro Polling-Durchlauf eine GET-Anfrage aus. Speichern Sie nicht abgeschlossene Arbeit an einem Ort, auf den der nächste Durchlauf zugreifen kann; verlassen Sie sich nicht auf eine Aufgaben-ID, die nur in der aktuellen Ausführung existiert.

1. 1.

   Einstiegspfad wählen

   Wenn der Auftrag bereits eine Aufgaben-ID hat, gehen Sie direkt zu GET. Nur ein neuer Auftrag ohne vorhandene Aufgabe sollte den Erstellungspfad durchlaufen.

2. 2.

   Durchläufe mit nicht abgeschlossenen Aufgaben beenden

   Behalten Sie bei pending oder solving die Aufgaben-ID und beenden Sie den Durchlauf. Rufen Sie beim Fortsetzen dieselbe ID ab. Markieren Sie Aufgaben mit Endstatus als geschlossen, damit spätere Polling-Durchläufe ihre Ergebnisse nicht erneut verarbeiten.

3. 3.

   Wiederholungen begrenzen

   Wenn Sie stattdessen einen Repeater hinzufügen, legen Sie eine endliche Höchstzahl fest und wiederholen Sie nur GET für die gespeicherte ID. Verhindern Sie nach ready oder failed weiteres Polling oder weitere Ergebnisverarbeitung. Wenn das Wiederholungslimit erreicht ist, müssen Sie stoppen und die ID behalten, statt eine Ersatzaufgabe zu erstellen.

Bei dieser reCAPTCHA-Anfrage ist solution.token der zu übermittelnde Wert, nicht die Aufgaben-ID. Verwenden Sie beim Übermitteln an das vorgesehene Ziel die zurückgegebene Browseridentität aus userAgent und secChUa zusammen mit dem erfolgreichen Proxy.

Gehen Sie nicht davon aus, dass das HTTP-Modul von Make für diese abschließende Anfrage den Kundenproxy des Solvers verwenden kann. Übergeben Sie das fertige Ergebnis an einen Client, der den erforderlichen Proxy und die Browseridentität unterstützt. ready bedeutet, dass die Lösung generiert wurde; ob sie akzeptiert wird, bestimmt die Antwort des Ziels auf die anschließende Übermittlung.