Usa la API de tareas de CAPTCHA en Make

Primero, configura en tu espacio de trabajo un perfil activo para el nombre de host de destino. Enviar site y action no crea un perfil. Consulta la configuración del perfil del sitio si el destino aún no está configurado.

1. 1.

   Configura la autenticación de HTTP v4

   Elige el tipo de autenticación API key y crea un llavero de credenciales. Establece la clave en Bearer seguido de un espacio y de tu clave de API del espacio de trabajo, la ubicación en In the header y el nombre del parámetro en Authorization. Restringe los orígenes de servicio permitidos a https://api.solvethree.com. Mantén la clave en el llavero en lugar de pasarla a través de los datos del escenario.

2. 2.

   Introduce la configuración de la solicitud

   Usa el método, la URL, el parámetro de consulta, el encabezado y el cuerpo JSON que se muestran a continuación. Introduce cada uno en su campo correspondiente del módulo. Solo el contenido de body debe incluirse en el contenido JSON de la solicitud; el ejemplo completo es una configuración explicativa, no un blueprint importable de Make.

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

• Sustituye site por el nombre de host configurado, no por una URL completa. Establece action en la acción que usa el flujo de destino.
• Sustituye proxy por la URL de tu proxy. La solicitud requiere exactamente uno de los campos proxy o proxyCandidates; el ejemplo usa un único proxy.
• Asigna a cada nuevo trabajo lógico su propio requestId y consérvalo para la recuperación. El valor del ejemplo es un marcador de posición, no un ID que debas reutilizar en trabajos no relacionados.
• No añadas type ni url a esta solicitud de reCAPTCHA. Si se omite recaptchaType, su valor predeterminado es enterprise-v3.

Tras una respuesta de creación satisfactoria, guarda el ID de tarea devuelto asociado al trabajo lógico antes de continuar. Añade un módulo de solicitud HTTP independiente para consultar esa tarea.

Gestiona las respuestas HTTP no satisfactorias antes de dirigir el flujo según el estado de la tarea. Un error HTTP no es lo mismo que una tarea cuyo estado es failed; no trates una respuesta ilegible o no satisfactoria como otro resultado pending.

Una vez que GET se complete correctamente, añade un enrutador con filtros explícitos sobre el status devuelto. No envíes todas las respuestas HTTP satisfactorias por la ruta de la solución.

Mantén explícito el filtro de tareas sin terminar en lugar de convertirlo en una ruta para todos los demás casos. Si el estado falta o es inesperado, debe inspeccionarse, no consultarse indefinidamente sin avisar. En la ruta de fallo, investiga el error indicado antes de crear otra tarea; reintentar entradas no válidas sin modificarlas no mejorará el resultado.

Un diseño sencillo y acotado realiza una solicitud GET por cada ejecución de consulta periódica. Guarda el trabajo sin terminar en un lugar que la siguiente ejecución pueda leer; no dependas de un ID de tarea que solo exista en la ejecución actual.

1. 1.

   Elige la ruta de entrada

   Si el trabajo ya tiene un ID de tarea, ve directamente a GET. Solo un trabajo nuevo sin una tarea existente debe entrar en la ruta de creación.

2. 2.

   Finaliza las ejecuciones con tareas sin terminar

   Para pending o solving, conserva el ID de tarea y finaliza la ejecución. Al reanudar, consulta ese mismo ID. Marca las tareas en estado terminal como cerradas para que las ejecuciones posteriores de consulta periódica no vuelvan a procesar sus resultados.

3. 3.

   Limita cualquier repetidor

   Si en su lugar añades un repetidor, asígnale un número máximo finito de repeticiones y repite solo GET para el ID guardado. Impide que se sigan realizando consultas o procesando resultados después de ready o failed. Alcanzar el límite de repeticiones significa detenerse y conservar el ID, no crear una tarea de sustitución.

Para esta solicitud de reCAPTCHA, el valor que debes enviar es solution.token, no el ID de tarea. Usa la identidad de navegador devuelta en userAgent y secChUa con el proxy que funcionó al enviar la solución al destino previsto.

No supongas que el módulo HTTP de Make puede usar el proxy del cliente utilizado por el servicio de resolución para esa solicitud final. Entrega el resultado listo a un cliente compatible con el proxy y la identidad de navegador requeridos. ready significa que se ha generado la solución; su aceptación la determina la respuesta del destino al envío posterior.