Verificações do site

Quando um destino executa uma verificação de bot no caminho para a página solicitada, o FourA avisa você. Cada request que encontra uma verificação retorna com um campo indicando o sistema, se a verificação foi superada e (em caso de sucesso) a autorização de clearance que você pode reutilizar para que a próxima chamada a ignore.

Esta página é a referência para esses campos. Para estratégia, consulte Protected sites.

Onde o campo fica

A ausência significa que nada foi reconhecido. Não interprete a falta de defense como uma falha.

No Single e Proxy, o relatório precisa de unblocker, que está ativado por padrão. Com unblocker: false você solicitou a página exatamente como ela veio, portanto o Single entrega o challenge intacto e o Browser o renderiza sem resolver.

defense no Single e Proxy

{
  "status": 200,
  "data": "<!doctype html>...",
  "total_time": 3.61,
  "defense": {
    "vendor": "sgcaptcha",
    "solved": true,
    "present": ["sgcaptcha"],
    "ms": 3412,
    "hashes": 1048576,
    "complexity": 20,
    "cookie": "_I_=<clearance>"
  }
}

solved: false é o caso que vale a pena tratar em ramificações. O FourA nunca apresenta uma página de desafio como conteúdo, portanto a flag é o seu sinal de que o corpo precisa de escalonamento em vez de análise.

retry: "refusal-cookies"

Alguns sites não executam um quebra-cabeça. Eles recusam a primeira request, definem cookies na recusa e entregam a página real a qualquer um que reenviar esses cookies. As páginas de itens do eBay são o caso de referência.

Quando isso acontece, o FourA os reenvia para você e entrega a página. A response então inclui retry: "refusal-cookies":

{
  "status": 200,
  "data": "<!doctype html>...",
  "defense": {
    "vendor": "akamai",
    "solved": false,
    "present": ["akamai"],
    "retry": "refusal-cookies",
    "cookie": "bm_sv=...; dp1=..."
  }
}

Leia da seguinte forma:

• solved permanece false. Responder a um handshake não é liberar um challenge e nunca altera o custo da chamada. Você é cobrado pela request feita.
• data é conteúdo real, não uma página de challenge. Este é o único caso em que solved: false não significa que o body precisa de escalonamento, e é por isso que o campo existe.
• cookie é a sessão fornecida pelo site. Faça o replay da mesma forma que faria o replay de uma liberação e as páginas seguintes ignoram a recusa.
• Um retry e um clear podem acontecer na mesma request. Se a resposta do retry acabou sendo um challenge que a FourA consegue liberar, você recebe solved: true com os campos do próprio fornecedor e retry: "refusal-cookies" ao lado deles.

vendor exibe unknown quando um retry gerou o conteúdo e nenhum sistema foi reconhecido no caminho. present será então um array vazio.

defenses no Browser

{
  "status": 200,
  "body": "<!doctype html>...",
  "userAgent": "Mozilla/5.0...",
  "defenseSolved": true,
  "defenses": {
    "present": ["cloudflare"],
    "cleared": ["cloudflare"]
  }
}

Um nome em present que nunca chega a cleared é um sistema que o FourA consegue reconhecer, mas ainda não consegue concluir. Esses nunca aumentam o preço de uma chamada.

Fornecedores

O Que É Liberado Hoje

Todo o resto na lista é apenas reconhecido e relatado, nada mais. Essa divisão muda conforme o FourA aprende a liberar mais deles, então leia solved em vez de assumir a partir desta tabela.

Duas observações sobre casos específicos:

• hcaptcha e recaptcha também são widgets normais de formulário. Eles só são relatados quando a resposta realmente bloqueou você (403, 429 ou 503), portanto uma página de checkout com um widget de verificação em um formulário não relata uma defesa.
• Estar atrás da Cloudflare não é uma defesa. cloudflare aparece quando há um desafio real ou artefato de gerenciamento de bots na resposta, não apenas porque um site usa Cloudflare.

Reproduzindo uma Liberação

defense.cookie é o objetivo principal do campo. Uma liberação é vinculada à saída que a obteve e ao User-Agent que a obteve, portanto reproduza-a pelo mesmo par e a verificação não será executada novamente.

import requests

API = "https://eu.api.foura.ai"
H = {"X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json"}

# 1) First call pays for the clear.
first = requests.post(f"{API}/api/proxy/", headers=H, json={
    "maxTries": 5,
    "request": {"method": "GET", "url": "https://example.com/catalog"},
}).json()

defense = first.get("defense", {})
if defense.get("solved"):
    clearance = defense["cookie"]
    exit_id = first["proxy"]

    # 2) Follow-up pages skip the check: same exit, same clearance.
    for page in range(2, 6):
        r = requests.post(f"{API}/api/single/", headers=H, json={
            "method": "GET",
            "url": f"https://example.com/catalog?page={page}",
            "proxy": exit_id,
            "headers": [["Cookie", clearance]],
        }).json()
        print(page, r["status"])

A primeira chamada arca com o custo da liberação. Cada repetição é uma request comum pelo preço comum.

Três coisas invalidam uma repetição:

1. Uma saída diferente. Fixe o ID do proxy retornado pela response de liberação. Veja Reutilizar um Proxy Entre Requests.
2. Um User-Agent diferente. As responses do Browser retornam o userAgent utilizado. Envie-o de volta com o cookie.
3. Expiração. As liberações têm tempos de vida próprios, definidos pelo destino. A do SiteGround dura cerca de 30 dias para o site inteiro; uma liberação da Cloudflare costuma ser muito mais curta. Trate uma liberação como cache: quando as repetições começarem a retornar desafios novamente, execute uma nova chamada e obtenha a nova liberação.

Quanto custa

Uma verificação liberada altera o preço apenas no Browser:

O Browser cobra 10 apenas quando o solver estava ativo e um sistema foi realmente liberado. Um sistema que foi reconhecido e não liberado custa 5, o mesmo que uma página sem nenhuma verificação.

Uma página de verificação reconhecida pelo FourA retornada com HTTP 200 (por exemplo, a verificação de robôs da Amazon, a página de verificação do Reddit ou a verificação de JavaScript da Busca do Google) não é cobrada em nenhum endpoint; a response a identifica em X-FourA-Check-Page.

Combine com validate

defense informa que uma verificação foi encontrada. validate informa ao FourA como é a página real, permitindo que uma request falhe em vez de entregar um interstitial que por acaso retorne HTTP 200.

{
  "method": "GET",
  "url": "https://example.com/product/42",
  "validate": {
    "data": {"accept": ["Add to cart"], "fail": ["Just a moment"]}
  }
}

No POST /api/auto/, o validate é o que impede a sequência de aceitar uma página de desafio e considerá-la concluída.

Relacionados

• Sites protegidos: Qual engine utilizar em cada nível de proteção
• Endpoints da API: Referência de request e response para todos os quatro endpoints
• Reutilizar um Proxy Entre Requests: Fixe a saída à qual uma liberação está vinculada
• Smart Fetch (Auto): Como o meta.solved se encaixa na sequência
• Response Headers: Onde o custo em créditos de uma chamada é exibido