Gérer les résultats des tâches CAPTCHA en toute sécurité en TypeScript

Utilisez les types exportés par le SDK : TaskRequest pour les données d’entrée et TaskResult pour les réponses. L’affinement selon le statut permet à TypeScript de distinguer un traitement inachevé, un échec et un résultat prêt, sans any ni assertion de type qui demande simplement au compilateur de vous faire confiance.

import { Solvethree, type TaskRequest, type TaskResult } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY! });
const input: TaskRequest = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY! };
function inspect(result: TaskResult): void {
  switch (result.status) {
    case 'pending':
    case 'solving':
      console.log('Retrieve this task again:', result.id);
      return;
    case 'failed':
      console.error('Failed task:', result.id, result.errorCode);
      return;
    case 'ready':
      // Solution fields depend on the requested product; check optional fields.
      if (!result.solution.token || !result.solution.userAgent || !result.solution.secChUa) {
        throw new Error('Expected a complete reCAPTCHA solution');
      }
      console.log('Ready task:', result.id);
      // Submit token privately with its browser identity and original proxy.
      return;
  }
}
inspect(await client.createTask(input, { waitMs: 0 }));
// Save the returned ID and call getTask while pending/solving with a deadline.

L’exemple crée une tâche et examine la réponse immédiate. pending et solving indiquent qu’il faut la récupérer à nouveau ; failed arrête le traitement ; ready mène aux vérifications de la solution. Si vous extrayez la branche ready dans une fonction auxiliaire, utilisez le type exporté ReadyTask pour son paramètre. Cela restreint le statut, mais ne rend pas obligatoires tous les champs de solution propres à chaque produit.

Les vérifications portent sur la présence d’un jeton et des deux champs d’identité du navigateur, car cette entrée demande reCAPTCHA. Elles ne prouvent pas que le jeton sera accepté par la cible. L’exemple n’affiche volontairement pas le jeton.

• Utilisez Node.js 22+ et l’installation du SDK officiel depuis une archive tarball décrite dans la documentation de l’API ; ne supposez pas qu’une version existe dans le registre npm.
• Définissez SOLVETHREE_API_KEY et SOLVETHREE_PROXY dans l’environnement du serveur. Les assertions ! ne vérifient pas à l’exécution si des variables d’environnement sont manquantes.
• Remplacez accounts.example.com et login par le nom d’hôte et l’action souhaités. Le site doit déjà disposer d’un profil actif dans l’espace de travail ; consultez la configuration du profil de site.

L’exemple laisse l’interrogation à la charge de l’appelant. Gardez la création en dehors de cette boucle : rappeler createTask ne permet pas de vérifier si la première tâche est terminée.

1. 1.

   Enregistrez l’ID renvoyé à la création

   Vérifiez que l’ID renvoyé est une chaîne non vide avant de l’utiliser pour récupérer la tâche. Conservez son association avec la requête d’origine, dont vous aurez également besoin pour sélectionner le proxy ayant réussi.

2. 2.

   Récupérez cette même tâche

   Appelez getTask avec l’ID enregistré tant que le statut est pending ou solving, en fixant une échéance locale. Avant de traiter chaque réponse, vérifiez que son ID correspond à l’ID enregistré. Un ID correspondant permet d’identifier la tâche traitée, pas de déterminer si elle a réussi.

3. 3.

   Arrêtez-vous à un résultat terminal

   Pour ready, validez les champs requis par le produit demandé. Pour failed, examinez à la fois errorCode et error, puis arrêtez d’interroger cette tâche. Traitez les erreurs de requête séparément : l’échec d’une requête de récupération ne constitue pas en soi un échec terminal de la tâche.

Si la création dépasse le délai avant que vous receviez un ID, ne supposez pas qu’aucune tâche n’a été créée. Si vous avez fourni un requestId, renvoyer la requête identique avec cette même valeur permet de récupérer la tâche existante. Réutiliser cette valeur avec des entrées modifiées provoque un conflit ; générer une nouvelle valeur ne permet pas de récupérer la tâche d’origine.

Choisissez le gestionnaire à partir de la requête d’origine, puis vérifiez les champs de solution attendus. La seule présence d’un jeton ne permet pas de distinguer une réponse reCAPTCHA d’une valeur de cookie TMPT.

Kasada en mode autonome prend actuellement en charge les cibles HTTPS sur www.ticketmaster.com, et non les sites arbitraires. Son gestionnaire d’en-têtes n’est pas une intégration Kasada universelle.

Pour chaque produit, envoyez la solution avec les valeurs userAgent et secChUa renvoyées et le proxy ayant réussi. Avec des proxys candidats, utilisez successfulProxy(originalTask, readyResult) plutôt que de supposer que le premier candidat a réussi. Le SDK n’applique pas la solution à la cible à votre place, et ready ne garantit pas l’acceptation de cette requête ultérieure.