Use a API de tarefas de CAPTCHA no Make

Primeiro, configure um perfil ativo para o hostname de destino no seu workspace. Enviar site e action não cria um perfil. Consulte a configuração do perfil do site se o destino ainda não estiver configurado.

1. 1.

   Configure a autenticação do HTTP v4

   Escolha o tipo de autenticação API key e crie um chaveiro de credenciais. Defina a chave como Bearer seguido de um espaço e da chave de API do seu workspace, o posicionamento como In the header e o nome do parâmetro como Authorization. Restrinja as origens de serviço permitidas a https://api.solvethree.com. Mantenha a chave no chaveiro em vez de passá-la pelos dados do cenário.

2. 2.

   Insira as configurações da requisição

   Use o método, a URL, o parâmetro de consulta, o cabeçalho e o corpo JSON mostrados abaixo. Insira cada um no campo correspondente do módulo. Apenas o conteúdo de body deve ser usado como conteúdo JSON da requisição; o exemplo completo é uma configuração explicativa, não um blueprint importável do 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"
    ]
  }
}

• Substitua site pelo hostname configurado, não por uma URL completa. Defina action como a ação usada pelo fluxo de destino.
• Substitua proxy pela URL do seu proxy. A requisição exige exatamente um dos campos: proxy ou proxyCandidates; o exemplo usa um único proxy.
• Atribua a cada novo trabalho lógico seu próprio requestId e guarde-o para recuperação. O valor do exemplo é ilustrativo, não um ID para reutilizar em trabalhos não relacionados.
• Não adicione type nem url a esta requisição reCAPTCHA. Quando recaptchaType é omitido, o padrão é enterprise-v3.

Após uma resposta de criação bem-sucedida, salve o ID da tarefa retornado associado ao trabalho lógico antes de continuar. Adicione um módulo de requisição HTTP separado para consultar essa tarefa.

Trate as respostas HTTP sem sucesso antes de encaminhar pelo status da tarefa. Um erro HTTP não é o mesmo que uma tarefa com status failed; não trate uma resposta ilegível ou sem sucesso como mais um resultado pending.

Após o GET ser bem-sucedido, adicione um roteador com filtros explícitos para o status retornado. Não encaminhe toda resposta HTTP bem-sucedida pela rota da solução.

Mantenha explícito o filtro de tarefas inacabadas em vez de torná-lo uma rota genérica. Um status ausente ou inesperado deve ser inspecionado, não consultado indefinidamente sem aviso. Na rota de falha, investigue o erro informado antes de criar outra tarefa; repetir os mesmos dados inválidos não resolverá o problema.

Um fluxo simples e limitado executa um GET por execução de consulta. Salve o trabalho inacabado em um local que a próxima execução possa ler; não dependa de um ID de tarefa que só existe na execução atual.

1. 1.

   Escolha o fluxo de entrada

   Se o trabalho já tiver um ID de tarefa, vá diretamente para GET. Apenas um novo trabalho sem tarefa existente deve entrar no fluxo de criação.

2. 2.

   Encerre execuções inacabadas

   Para pending ou solving, guarde o ID da tarefa e encerre a execução. Ao retomar, consulte esse mesmo ID. Marque as tarefas em estado final como encerradas para que execuções posteriores de consulta não processem seus resultados novamente.

3. 3.

   Limite qualquer repetidor

   Se, em vez disso, você adicionar um repetidor, defina um número máximo finito de repetições e repita apenas o GET para o ID salvo. Impeça novas consultas ou o processamento do resultado após ready ou failed. Atingir o limite de repetições significa parar e guardar o ID, não criar uma tarefa substituta.

Para esta requisição reCAPTCHA, o valor a enviar é solution.token, não o ID da tarefa. Use a identidade de navegador retornada em userAgent e secChUa com o proxy usado na resolução bem-sucedida ao enviar ao destino pretendido.

Não suponha que o módulo HTTP do Make possa usar o proxy do cliente utilizado na resolução para essa requisição final. Entregue o resultado pronto a um cliente que ofereça suporte ao proxy e à identidade de navegador exigidos. ready significa que a solução foi gerada; a aceitação é determinada pela resposta do destino ao envio subsequente.