Gestiona los resultados de las tareas de CAPTCHA de forma segura en TypeScript

Usa los tipos exportados por el SDK: TaskRequest para la entrada y TaskResult para las respuestas. La acotación por estado permite a TypeScript distinguir entre trabajo sin terminar, fallo y solución lista sin usar any ni una conversión de tipos que simplemente le diga al compilador que confíe en ti.

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.

El ejemplo crea una tarea e inspecciona la respuesta inmediata. pending y solving indican que hay que volver a consultarla; failed detiene el procesamiento; ready da paso a las comprobaciones de la solución. Si extraes la rama ready a una función auxiliar, usa el tipo exportado ReadyTask para su parámetro. Eso acota el estado, pero no hace obligatorios todos los campos de solución específicos de cada producto.

Las comprobaciones verifican la presencia de un token y de ambos campos de identidad del navegador porque esta entrada solicita reCAPTCHA. No demuestran que el destino vaya a aceptar el token. El ejemplo evita imprimir el token de forma deliberada.

• Usa Node.js 22+ y la instalación del SDK oficial mediante un archivo tarball documentada en la documentación de la API; no des por hecho que existe una versión publicada en el registro npm.
• Define SOLVETHREE_API_KEY y SOLVETHREE_PROXY en el entorno del servidor. Las aserciones ! no comprueban en tiempo de ejecución si faltan variables de entorno.
• Sustituye accounts.example.com y login por el nombre de host y la acción previstos. El sitio ya debe tener un perfil activo en el espacio de trabajo; consulta la configuración del perfil del sitio.

El ejemplo deja las consultas periódicas a cargo del código que lo invoca. Mantén la creación fuera de ese bucle: volver a llamar a createTask no es la forma de comprobar si la primera tarea ha terminado.

1. 1.

   Guarda el ID del resultado de la creación

   Comprueba que el ID devuelto sea una cadena no vacía antes de usarlo para consultar la tarea. Mantenlo asociado a la solicitud original, que también necesitarás para seleccionar el proxy que tuvo éxito.

2. 2.

   Consulta esa misma tarea

   Llama a getTask con el ID guardado mientras el estado sea pending o solving, con un plazo límite local. Antes de procesar cada respuesta, comprueba que su ID coincida con el ID guardado. La coincidencia del ID permite saber qué tarea estás gestionando, no si ha tenido éxito.

3. 3.

   Detente al alcanzar un resultado terminal

   Con ready, valida los campos que requiere el producto solicitado. Con failed, inspecciona tanto errorCode como error y deja de consultar esa tarea. Gestiona los errores de solicitud por separado: que falle una solicitud de consulta no constituye por sí mismo un fallo terminal de la tarea.

Si la creación agota el tiempo de espera antes de que recibas un ID, no des por hecho que no se ha creado ninguna tarea. Si proporcionaste un requestId, reenviar la solicitud idéntica con ese mismo valor recupera la tarea existente. Reutilizarlo con entradas distintas genera un conflicto; generar un valor nuevo no recupera la tarea original.

Elige el manejador a partir de la solicitud original y comprueba después los campos de solución esperados. La mera presencia de un token no permite distinguir una respuesta de reCAPTCHA de un valor de cookie TMPT.

Kasada independiente admite actualmente destinos HTTPS en www.ticketmaster.com, no sitios arbitrarios. Su manejador de encabezados no es una integración universal de Kasada.

Para cada producto, realiza el envío con los valores devueltos de userAgent y secChUa y el proxy que tuvo éxito. Si usas candidatos de proxy, usa successfulProxy(originalTask, readyResult) en lugar de suponer que el primer candidato tuvo éxito. El SDK no aplica la solución al destino por ti, y ready no garantiza que esa solicitud posterior sea aceptada.