Appeler l’API CAPTCHA depuis PowerShell
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.
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.
Fournir les variables d’environnement
Définissez
SOLVETHREE_API_KEYetSOLVETHREE_PROXYdans 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.
Remplacez le nom d’hôte et l’action de l’exemple
Remplacez
accounts.example.cometloginpar 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 champtypeni du champurl.
Créer une seule fois, puis interroger l’identifiant de tâche
#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.errorCodeet$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-unreachableest 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.
Si vous avez un ID de tâche, récupérez cette tâche
Poursuivez avec GET
/v1/tasks/:idau 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.
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
requestIdpour récupérer la tâche existante. Modifier les entrées tout en réutilisant cet ID provoque un conflit. - 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.
Sources et référence de l’API
Lancez votre première tâche.
Démarrez avec $5 de crédit dans votre espace de travail.