Appeler l’API CAPTCHA depuis PowerShell

Par solvethree5 min de lecture

Utilisez PowerShell 7.5+ et Invoke-RestMethod pour appeler solvethree directement. Le script ci-dessous crée une seule tâche reCAPTCHA Enterprise et interroge le même identifiant de tâche jusqu’à sa fin ou jusqu’à épuisement du budget d’attente local.

Sur cette page

Définir les identifiants d’authentification et les paramètres cibles

  1. 1.

    Rendre le site disponible dans votre espace de travail

    Configurez un profil actif pour le nom d’hôte cible dans la console. L’envoi d’un nom d’hôte et d’une action n’en crée pas. Consultez la configuration du profil de site si cela n’a pas encore été fait.

  2. 2.

    Fournir les variables d’environnement

    Définissez SOLVETHREE_API_KEY et SOLVETHREE_PROXY dans l’environnement du processus PowerShell à l’aide de votre mécanisme habituel de gestion des secrets. Vérifiez que les deux variables ont une valeur avant l’exécution. La clé API est transmise dans un en-tête Bearer ; elle ne doit pas figurer dans le JSON de la tâche.

  3. 3.

    Remplacez le nom d’hôte et l’action de l’exemple

    Remplacez accounts.example.com et login par le nom d’hôte et l’action requis par votre intégration. Utilisez un nom d’hôte, pas une URL complète. La requête utilise Enterprise v3 par défaut et n’a donc besoin ni du champ type ni du champ url.

Créer une seule fois, puis interroger l’identifiant de tâche

PowerShell · créer une seule fois et conserver l’identifiant de récupération
#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
}

Le script envoie une seule requête POST à /v1/tasks?waitMs=0. Les requêtes suivantes sont des GET pour l’ID renvoyé, avec waitMs=15000. Les statuts pending et solving maintiennent la boucle ; tout autre statut y met fin.

ConvertTo-Json sérialise la table de hachage de la tâche, sans recourir à du JSON dont les guillemets sont saisis manuellement ni à une commande shell. L’ID de tâche est échappé pour les URL avant les interrogations. Conservez ces éléments lorsque vous adaptez l’exemple.

Le chronomètre Stopwatch vérifie un budget local de 180 secondes avant chaque appel API. Chaque appel dispose de délais de connexion et d’opération d’au plus 25 secondes, réduits à mesure que le budget s’épuise. Après une interrogation renvoyant un statut non terminal, le script attend une seconde. Ce budget évite les interrogations sans fin ; il ne garantit pas un arrêt à une durée réelle exacte.

MaximumRetryCount = 0 désactive les nouvelles tentatives HTTP automatiques, et MaximumRedirection = 0 refuse les redirections. Les paramètres de délai utilisés ici nécessitent PowerShell 7.5+, et non n’importe quelle installation de PowerShell 7. La référence Invoke-RestMethod de Microsoft documente ces paramètres.

Utilisez le jeton, pas l’ID de tâche

Au statut ready, la valeur reCAPTCHA à soumettre est $result.solution.token. $taskId identifie uniquement la tâche solvethree. L’exemple s’arrête avant d’envoyer la requête applicative à votre cible.

Soumettez le jeton avec les valeurs userAgent et secChUa de la solution renvoyée, en utilisant le proxy d’origine. Ne leur substituez pas une identité de navigateur sans rapport et n’envoyez pas le jeton à une autre cible. ready signifie que solvethree a généré une solution ; cela ne prouve pas que la cible a accepté votre requête applicative.

Invoke-RestMethod lève une exception HTTP ou de connexion

La requête API a échoué avant que le script puisse traiter une réponse de réussite. Le bloc catch affiche les identifiants de récupération et relance l’exception d’origine.

Essayez ceci : Examinez le statut HTTP et les détails de la réponse, s’ils sont disponibles. Corrigez les entrées invalides au lieu de les renvoyer telles quelles. Si le résultat de la création de tâche est incertain, récupérez-la comme décrit ci-dessous.

La tâche renvoie failed

Examinez à la fois $result.errorCode et $result.error. L’exception levée par le script pour une tâche terminée ne contient que le code d’erreur.

Essayez ceci : Arrêtez d’interroger cette tâche et corrigez la cause signalée. Par exemple, site-unreachable est une erreur de tâche, pas une preuve que la requête API elle-même a échoué. Consultez les erreurs de l’API CAPTCHA.

Récupérez une requête au résultat incertain sans créer une autre tâche

Un dépassement de délai ne prouve pas que la requête de création a échoué. Le bloc catch affiche requestId et, s’il a été reçu, taskId. Conservez ces valeurs.

  1. 1.

    Si vous avez un ID de tâche, récupérez cette tâche

    Poursuivez avec GET /v1/tasks/:id au lieu de créer une autre tâche. Atteindre l’échéance locale du script ne prouve pas que la tâche distante a échoué.

  2. 2.

    Si la création n’a renvoyé aucun ID de tâche, réutilisez la requête d’origine

    Renvoyez les mêmes entrées de tâche avec le même requestId pour récupérer la tâche existante. Modifier les entrées tout en réutilisant cet ID provoque un conflit.

  3. 3.

    Ne redémarrez pas ce script pour effectuer la récupération

    Une nouvelle exécution génère un nouveau GUID, et donc une nouvelle requête logique. Pour une utilisation sans surveillance, enregistrez de manière sécurisée le requestId d’origine et les entrées de tâche avant le POST, puis enregistrez l’ID de tâche à sa réception. L’exemple affiche les identifiants de récupération en cas d’échec, mais ne les conserve pas en cas de perte du processus.

Ne consignez pas les entrées enregistrées dans les journaux ordinaires si l’URL du proxy contient des identifiants. Pour la récupération, vous avez besoin des entrées d’origine, pas d’une autre copie de la clé API.

Lancez votre première tâche.

Démarrez avec $5 de crédit dans votre espace de travail.

Créer un espace de travail
Appeler l’API CAPTCHA depuis PowerShell · solvethree