Utiliser l’API de tâches CAPTCHA dans Make

Commencez par configurer un profil actif pour le nom d’hôte cible dans votre espace de travail. Envoyer site et action ne crée pas de profil. Consultez la configuration du profil de site si la cible n’est pas encore configurée.

1. 1.

   Configurez l’authentification HTTP v4

   Choisissez le type d’authentification API key et créez un trousseau d’identifiants. Définissez la clé sur Bearer suivi d’un espace et de votre clé API d’espace de travail, l’emplacement sur In the header et le nom du paramètre sur Authorization. Limitez les origines de service autorisées à https://api.solvethree.com. Conservez la clé dans le trousseau plutôt que de la transmettre dans les données du scénario.

2. 2.

   Saisissez les paramètres de la requête

   Utilisez la méthode, l’URL, le paramètre de requête, l’en-tête et le corps JSON indiqués ci-dessous. Saisissez chaque élément dans le champ correspondant du module. Seul le contenu de body doit figurer dans le contenu JSON de la requête ; l’exemple complet est une configuration explicative, pas un blueprint Make importable.

{
  "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"
    ]
  }
}

• Remplacez site par le nom d’hôte configuré, et non par une URL complète. Définissez action sur l’action utilisée par le parcours cible.
• Remplacez proxy par l’URL de votre proxy. La requête exige exactement un des champs proxy ou proxyCandidates ; l’exemple utilise un seul proxy.
• Attribuez à chaque nouveau traitement logique son propre requestId et conservez-le pour la récupération. La valeur de l’exemple est une valeur de remplacement, pas un identifiant à réutiliser pour des traitements sans rapport.
• N’ajoutez pas type ni url à cette requête reCAPTCHA. Si recaptchaType est omis, sa valeur par défaut est enterprise-v3.

Après une réponse de création réussie, enregistrez l’identifiant de tâche renvoyé en l’associant au traitement logique avant de poursuivre. Ajoutez un module de requête HTTP distinct pour récupérer cette tâche.

Traitez les réponses HTTP d’échec avant d’acheminer selon le statut de la tâche. Une erreur HTTP n’est pas la même chose qu’une tâche dont le statut est failed ; ne traitez pas une réponse illisible ou d’échec comme un autre résultat pending.

Une fois GET réussi, ajoutez un routeur avec des filtres explicites sur le status renvoyé. N’envoyez pas toutes les réponses HTTP réussies vers la branche de traitement de la solution.

Gardez un filtre explicite pour les tâches inachevées plutôt que d’en faire une branche fourre-tout. Un statut manquant ou inattendu doit être examiné, et non interrogé indéfiniment en silence. Dans la branche d’échec, examinez l’erreur signalée avant de créer une autre tâche ; réessayer avec les mêmes données invalides ne résoudra rien.

Une conception simple et bornée effectue un GET par exécution d’interrogation. Enregistrez le travail inachevé dans un emplacement accessible à l’exécution suivante ; ne vous fiez pas à un identifiant de tâche qui n’existe que dans l’exécution en cours.

1. 1.

   Choisissez le parcours d’entrée

   Si le traitement possède déjà un identifiant de tâche, passez directement à GET. Seul un nouveau traitement sans tâche existante doit emprunter le parcours de création.

2. 2.

   Terminez les exécutions inachevées

   Pour pending ou solving, conservez l’identifiant de tâche et terminez l’exécution. À la reprise, récupérez ce même identifiant. Marquez les tâches terminées comme closes pour que les exécutions d’interrogation ultérieures ne traitent pas à nouveau leurs résultats.

3. 3.

   Limitez tout répéteur

   Si vous ajoutez plutôt un répéteur, attribuez-lui un nombre maximal fini de répétitions et ne répétez que GET pour l’identifiant enregistré. Empêchez toute interrogation ou tout traitement de résultat supplémentaire après ready ou failed. Atteindre la limite de répétitions signifie qu’il faut s’arrêter et conserver l’identifiant, et non créer une tâche de remplacement.

Pour cette requête reCAPTCHA, la valeur à soumettre est solution.token, et non l’identifiant de tâche. Utilisez l’identité de navigateur userAgent et secChUa renvoyée avec le proxy ayant permis la résolution lors de la soumission à la cible prévue.

Ne supposez pas que le module HTTP de Make peut utiliser le proxy du client employé par le solveur pour cette requête finale. Transmettez le résultat prêt à un client qui prend en charge le proxy et l’identité de navigateur requis. ready signifie que la solution a été générée ; son acceptation est déterminée par la réponse de la cible à la soumission suivante.