Trate resultados de tarefas de CAPTCHA com segurança em TypeScript

Use TaskRequest, exportado pelo SDK, para a entrada e TaskResult para as respostas. O refinamento por status permite que o TypeScript diferencie trabalho inacabado, falha e prontidão sem any nem uma conversão de tipo que apenas manda o compilador confiar em você.

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.

O exemplo cria uma tarefa e examina a resposta imediata. pending e solving indicam que ela deve ser consultada novamente; failed encerra o processamento; ready leva às verificações da solução. Se você extrair o ramo ready para uma função auxiliar, use o tipo exportado ReadyTask no parâmetro. Isso restringe o status, mas não torna obrigatório todo campo de solução específico de um produto.

As verificações conferem a presença de um token e dos dois campos de identidade do navegador porque esta entrada solicita reCAPTCHA. Elas não comprovam que um token será aceito pelo destino. O exemplo deliberadamente não imprime o token.

• Use Node.js 22+ e a instalação pelo tarball do SDK oficial documentada na documentação da API; não presuma que exista uma versão publicada no registro npm.
• Defina SOLVETHREE_API_KEY e SOLVETHREE_PROXY no ambiente do servidor. As asserções ! não validam variáveis de ambiente ausentes em tempo de execução.
• Substitua accounts.example.com e login pelo hostname e pela ação desejados. O site já deve ter um perfil ativo no workspace; consulte a configuração do perfil do site.

O exemplo deixa as consultas periódicas a cargo de quem o chama. Mantenha a criação fora desse loop: chamar createTask novamente não é a forma de verificar se a primeira tarefa terminou.

1. 1.

   Salve o ID retornado na criação

   Verifique se o ID retornado é uma string não vazia antes de usá-lo na consulta. Mantenha-o associado à solicitação original, que também será necessária para selecionar o proxy que teve sucesso.

2. 2.

   Consulte essa mesma tarefa

   Chame getTask com o ID salvo enquanto o status for pending ou solving, com um prazo limite local. Antes de processar cada resposta, verifique se o ID dela corresponde ao ID salvo. Um ID correspondente confirma qual tarefa você está tratando, não se ela teve sucesso.

3. 3.

   Pare ao receber um resultado terminal

   Em ready, valide os campos exigidos pelo produto solicitado. Em failed, examine tanto errorCode quanto error e pare de consultar essa tarefa. Trate os erros de solicitação separadamente: uma solicitação de consulta malsucedida não é, por si só, uma falha terminal da tarefa.

Se a criação atingir o tempo limite antes de você receber um ID, não presuma que nenhuma tarefa foi criada. Se você forneceu um requestId, reenviar a solicitação idêntica com esse mesmo valor recupera a tarefa existente. Reutilizá-lo com entradas alteradas gera conflito; gerar um novo valor não recupera a tarefa original.

Escolha o tratador com base na solicitação original e então verifique os campos de solução esperados. A presença de um token, por si só, não permite distinguir uma resposta reCAPTCHA de um valor de cookie TMPT.

Atualmente, o Kasada independente oferece suporte a destinos HTTPS em www.ticketmaster.com, não a sites arbitrários. Seu tratador de cabeçalhos não é uma integração universal com Kasada.

Para cada produto, envie com o userAgent e o secChUa retornados e com o proxy que teve sucesso. Ao usar candidatos a proxy, use successfulProxy(originalTask, readyResult) em vez de presumir que o primeiro candidato foi o vencedor. O SDK não aplica a solução ao destino por você, e ready não garante a aceitação dessa solicitação subsequente.