Scarnox · Blog

Resolvendo PopularCaptcha invisível: como ele difere e o que enviar

O PopularCaptcha invisível parece não ser captcha nenhum. Não há caixa de "não sou um robô". O site chama o PopularCaptcha pelo próprio JavaScript, normalmente quando o visitante pressiona enviar, e mostra um desafio apenas se não tiver certeza sobre o visitante. Para um script de automação o widget é mais difícil de notar, mas a resolução continua sendo uma única requisição.

A Scarnox resolve PopularCaptcha hoje, inclusive a variante invisível. Você define uma flag, is_invisible, e envia a mesma requisição que enviaria para um widget visível. Outros tipos de captcha estão em breve.

Como saber que é invisível

O widget tem data-size="invisible".
O site chama a função execute() do widget no próprio código.
Há um sitekey na página, mas nenhuma caixa visível em lugar algum.

A configuração do sitekey é que determina isso, e não a aparência da página. Se tiver dúvida, encontre o sitekey e confira as opções do widget no JavaScript da página.

O que enviar

Use o mesmo endpoint e o mesmo tipo de tarefa, e adicione is_invisible com o valor true:

{
  "captcha_type": "PopularCaptchaTaskProxyless",
  "site_key": "10000000-ffff-ffff-ffff-000000000001",
  "site_url": "https://example.com/login",
  "is_invisible": true
}

Envie com a sua chave no cabeçalho Authorization: Bearer, como em todos os outros exemplos. A chamada bloqueia até o token estar pronto, sem polling. Use um timeout de cerca de 185 segundos.

Devolvendo o token

Integrações invisíveis quase sempre usam um callback em vez de um campo de formulário. O site passa um nome de função para o widget, seja no atributo data-callback, seja nas opções passadas para render(). Chame essa função com o token, e o código do próprio site continua como se o visitante tivesse passado no desafio:

await page.evaluate((t) => {
  document.querySelectorAll('[name="h-captcha-response"]').forEach((el) => { el.value = t; });
  const cb = document.querySelector("[data-sitekey]")?.dataset.callback;
  if (cb && typeof window[cb] === "function") window[cb](t);
}, token);

Preencher também o campo oculto não faz mal, e cobre sites que leem o campo no envio.

O tempo importa mais do que o normal

Com um widget invisível, quem decide quando o desafio roda é o site, e normalmente esse momento é o do envio pelo visitante. Por isso, resolva nesse momento, e não antes. O padrão mais simples é disparar a resolução logo antes de pressionar o botão no seu script, chamar o callback e então enviar.

Os tokens expiram em cerca de dois minutos. Um token obtido durante o carregamento da página e usado um minuto depois provavelmente será rejeitado.

Erro comum

Enviar um sitekey invisível como uma tarefa visível normal pode gerar um token que o site recusa. Se a API devolve um token, mas o site o rejeita, verifique estes pontos nesta ordem:

is_invisible está definido como true?
O site chama o callback, e faz isso antes de o formulário ser enviado?
A site_url é a página em que o widget invisível roda?
Se o site continuar recusando o token, o problema pode estar ligado ao IP que o resolveu. Compare com proxy versus resolução sem proxy.

Testando um fluxo invisível com segurança

Widgets invisíveis são difíceis de testar à mão, porque o desafio só roda no envio e, na maioria das vezes, passa sem mostrar nada. Teste nesta ordem:

Confirme que a resolução devolve um token com is_invisible definido como true, usando o teste rápido do guia de teste grátis.
Dispare você mesmo o callback do site no console do navegador, com esse token, e observe se o formulário continua.
Envie o formulário pelo seu script e verifique a página seguinte.
Repita a execução a partir de uma segunda rede, se for possível, para confirmar que o token não está preso ao IP que o resolveu.

Faça o teste em um formulário seu, ou em uma cópia de homologação do site que você tem permissão para testar. Nunca execute um fluxo invisível em uma conta real que você não controla.

A ordem dos eventos em um envio invisível

Uma integração que funciona segue esta sequência:

O visitante, ou o seu script, preenche o formulário.
O seu script lê o sitekey e a URL da página.
O seu script chama o endpoint de resolução com is_invisible definido como true e espera o token.
O seu script grava o token no campo de resposta e chama o callback do site.
O código do site envia o formulário com o token anexado.

Se o passo 3 acontecer bem antes do passo 5, o token pode expirar antes do envio do formulário. Mantenha a diferença o mais curta possível.

Quando o site rejeita um token invisível

Uma rejeição nem sempre é um problema com o token. Verifique estes pontos antes de mudar a requisição de resolução:

O callback rodou antes de o formulário ser enviado, e não depois.
O formulário lê o token do campo em que o seu script gravou. Alguns sites usam um campo diferente para widgets invisíveis.
A requisição que carrega o token veio da mesma sessão que carregou a página. Cookies de outra sessão não batem.
A página não recarregou entre a resolução e o envio, o que descartaria o token.

Só depois dessas verificações passe para a questão do proxy. A maioria das rejeições vem do callback ou da sessão, e não do IP.

Próximos passos

Comece com crédito de teste grátis, sem cartão: crie uma conta e teste um sitekey invisível em uma página sua.