Die CAPTCHA-API aus PowerShell aufrufen

1. 1.

   Website für Ihren Arbeitsbereich verfügbar machen

   Konfigurieren Sie in der Konsole ein aktives Profil für den Zielhostname. Das Senden eines Hostnamens und einer Aktion erstellt keines. Siehe Website-Profil einrichten, falls dies noch nicht geschehen ist.

2. 2.

   Umgebungsvariablen bereitstellen

   Setzen Sie SOLVETHREE_API_KEY und SOLVETHREE_PROXY in der Umgebung des PowerShell-Prozesses mit Ihrem üblichen Verfahren für den Umgang mit Geheimnissen. Prüfen Sie vor der Ausführung, ob beide Werte gesetzt sind. Der API-Schlüssel wird als Bearer-Header verwendet; er gehört nicht in das Task-JSON.

3. 3.

   Beispiel-Hostname und -Aktion ersetzen

   Ersetzen Sie accounts.example.com und login durch den Hostnamen und die Aktion, die Ihre Integration benötigt. Verwenden Sie einen Hostnamen, keine vollständige URL. Die Anfrage verwendet standardmäßig Enterprise v3 und benötigt daher weder ein type- noch ein url-Feld.

#requires -Version 7.5
$ErrorActionPreference = 'Stop'
$apiBase = 'https://api.solvethree.com/v1'
$headers = @{ Authorization = "Bearer $env:SOLVETHREE_API_KEY"; Accept = 'application/json' }
$taskInput = @{ site = 'accounts.example.com'; action = 'login'; proxy = $env:SOLVETHREE_PROXY; requestId = [guid]::NewGuid().ToString() }
$requestClock = [Diagnostics.Stopwatch]::StartNew()
function Call-TaskApi($Method, $Path, $Payload = $null) {
    $remaining = 180 - $requestClock.Elapsed.TotalSeconds
    if ($remaining -le 0) { throw 'Local deadline reached' }
    $seconds = [int][Math]::Ceiling([Math]::Min(25, $remaining))
    $options = @{ Method = $Method; Uri = "$apiBase$Path"; Headers = $headers;
        ConnectionTimeoutSeconds = $seconds; OperationTimeoutSeconds = $seconds;
        MaximumRetryCount = 0; MaximumRedirection = 0 }
    if ($null -ne $Payload) { $options.Body = $Payload | ConvertTo-Json -Depth 6; $options.ContentType = 'application/json' }
    Invoke-RestMethod @options
}
$taskId = $null
try {
    $result = Call-TaskApi 'POST' '/tasks?waitMs=0' $taskInput
    $taskId = $result.id
    while ($result.status -in @('pending', 'solving')) {
        $escapedId = [uri]::EscapeDataString($taskId)
        $result = Call-TaskApi 'GET' "/tasks/$escapedId`?waitMs=15000"
        if ($result.status -in @('pending', 'solving')) { Start-Sleep -Seconds 1 }
    }
    if ($result.status -ne 'ready') { throw "Task failed: $($result.errorCode)" }
    Write-Host "Ready task: $taskId"
    # Submit $result.solution.token with userAgent/secChUa and the original proxy.
} catch {
    Write-Host "Recovery requestId=$($taskInput.requestId) taskId=$taskId"
    throw
}

Das Skript sendet einmal POST an /v1/tasks?waitMs=0. Nachfolgende Anfragen sind GET-Anfragen für die zurückgegebene ID mit waitMs=15000. Bei pending und solving läuft die Schleife weiter; jeder andere Status beendet sie.

ConvertTo-Json serialisiert die Hashtable des Tasks, statt sich auf manuell gesetzte Anführungszeichen im JSON oder einen Shell-Befehl zu verlassen. Die Task-ID wird vor dem Polling URL-kodiert. Behalten Sie diese Schritte bei, wenn Sie das Beispiel anpassen.

Die Stopwatch prüft vor jedem API-Aufruf ein lokales Zeitbudget von 180 Sekunden. Jeder Aufruf erhält Verbindungs- und Ausführungszeitlimits von höchstens 25 Sekunden, die sich mit dem verbleibenden Budget verkürzen. Nach einem Polling-Aufruf mit nicht abschließendem Status pausiert das Skript eine Sekunde. Das Budget verhindert endloses Polling; es ist keine exakte Grenze für die tatsächliche Laufzeit.

MaximumRetryCount = 0 deaktiviert automatische HTTP-Wiederholungen, und MaximumRedirection = 0 verhindert Weiterleitungen. Die hier verwendeten Timeout-Parameter erfordern PowerShell 7.5+, nicht nur eine beliebige PowerShell-7-Installation. Microsoft dokumentiert diese Parameter in der Invoke-RestMethod-Referenz.

Bei ready ist der zu übermittelnde reCAPTCHA-Wert $result.solution.token. $taskId identifiziert lediglich den solvethree-Task. Das Beispiel endet, bevor die Anwendungsanfrage an Ihr Ziel gesendet wird.

Übermitteln Sie das Token zusammen mit userAgent und secChUa aus der zurückgegebenen Lösung über den ursprünglichen Proxy. Ersetzen Sie diese Werte nicht durch eine andere Browseridentität und senden Sie das Token nicht an ein anderes Ziel. ready bedeutet, dass solvethree eine Lösung generiert hat; es bestätigt nicht, dass das Ziel Ihre Anwendungsanfrage akzeptiert hat.

Invoke-RestMethod löst eine HTTP- oder Verbindungsausnahme aus

Die API-Anfrage ist fehlgeschlagen, bevor das Skript eine erfolgreiche Antwort verarbeiten konnte. Der catch-Block gibt IDs zur Wiederherstellung aus und löst die ursprüngliche Ausnahme erneut aus.

Probiere Folgendes: Prüfen Sie den HTTP-Status und die Antwortdetails, sofern verfügbar. Korrigieren Sie ungültige Eingaben, statt sie unverändert erneut zu senden. Falls unklar ist, ob der Task erstellt wurde, stellen Sie ihn wie unten beschrieben wieder her.

Die Aufgabe gibt failed zurück

Prüfen Sie sowohl $result.errorCode als auch $result.error. Die Ausnahme des Skripts für einen abgeschlossenen Task enthält nur den Fehlercode.

Probiere Folgendes: Beenden Sie das Polling für diesen Task und beheben Sie die gemeldete Ursache. Beispielsweise ist site-unreachable ein Task-Fehler und kein Beleg dafür, dass die API-Anfrage selbst fehlgeschlagen ist. Siehe Fehler der CAPTCHA-API.

Eine Zeitüberschreitung beweist nicht, dass die Erstellungsanfrage fehlgeschlagen ist. Der catch-Block gibt requestId und, falls empfangen, taskId aus. Bewahren Sie diese Werte auf.

1. 1.

   Wenn Sie eine Task-ID haben, rufen Sie diesen Task ab

   Fahren Sie mit GET /v1/tasks/:id fort, statt einen weiteren Task zu erstellen. Dass die lokale Zeitgrenze des Skripts erreicht wurde, bedeutet nicht, dass der entfernte Task fehlgeschlagen ist.

2. 2.

   Wenn die Erstellung keine Task-ID zurückgegeben hat, die ursprüngliche Anfrage erneut verwenden

   Senden Sie dieselben Task-Eingaben mit derselben requestId erneut, um den vorhandenen Task wiederherzustellen. Wenn Sie die Eingaben ändern und dabei diese ID wiederverwenden, entsteht ein Konflikt.

3. 3.

   Das Skript zur Wiederherstellung nicht neu starten

   Ein neuer Durchlauf generiert eine neue GUID und damit eine neue logische Anfrage. Speichern Sie für den unbeaufsichtigten Einsatz die ursprüngliche requestId und die Task-Eingaben vor dem POST sicher ab und anschließend die Task-ID, sobald sie eintrifft. Das Beispiel gibt bei Fehlern IDs zur Wiederherstellung aus, speichert sie aber nicht über das Ende des Prozesses hinaus.

Halten Sie die gespeicherten Eingaben aus gewöhnlichen Protokollen fern, wenn die Proxy-URL Zugangsdaten enthält. Zur Wiederherstellung benötigen Sie die ursprünglichen Eingaben, keine weitere Kopie des API-Schlüssels.