TodosNovoMelhoriaCorrigido
Melhoria

A tabela Activity cabe em um laptop, painel recebe abas

O painel Activity agora cabe em um MacBook de 14" sem rolagem horizontal, e cada coluna mantém seu valor. O painel de detalhes possui um formato de abas (Request, Response headers, Response body), de modo que a resposta fica na parte superior em vez de 900px abaixo. As tooltips seguem o seu ponteiro e exibem a URL completa.

Melhoria

Atividade mostra o request que você realmente enviou

A coluna de método agora lê o verbo do corpo do seu request (GET, POST, PUT, etc.), em vez de sempre exibir POST porque foi isso que a nossa camada de API recebeu. As chamadas do Playground também registram o IP do navegador da pessoa que clicou em Send, para que uma conta compartilhada possa saber quem executou o quê.

Novo

Escolha o navegador que a sua request MCP apresenta

O FourA MCP 0.6.0 permite que um agente escolha qual navegador uma request apresenta. foura_single e foura_proxy aceitam browser, os, version ou um id exato de profile do catálogo público em GET /api/profiles. Eles viajam dentro da request que já vai para o upstream, então não há chamada extra. Deixe-os de fora e a request apresenta o Google Chrome mais recente, exatamente como antes. Uma combinação que o catálogo não pode apresentar retorna como um erro listando o que está disponível, de modo que uma request nunca é enviada como um navegador que você não escolheu.

Ambas as ferramentas agora retornam defense quando o alvo executa uma verificação de bot. defense.solved: false significa que o body pode ser uma página de desafio em vez do conteúdo que você solicitou, o que é o sinal para tentar novamente com um navegador diferente ou escalar, em vez de fazer o parse de uma página de bloqueio como dados.

Uma correção na mesma versão: a descrição de unblocker dizia que o seu padrão era desligado. Ele sempre esteve ligado, então as requests já carregavam um conjunto completo de header de navegador. O esquema publicado agora corresponde ao comportamento.

Melhoria

Uma instância lenta agora consta como degradada

Uma instância saturada responde a um health check em 3 a 10 segundos, enquanto uma saudável leva de 9 a 225 milissegundos, e ambas costumavam constar como normais. O status lento agora consta como degradado, carregando o próprio motivo da instância, para que possamos ver o problema enquanto ainda é apenas um servidor lento e não uma falha no seu request. O Auto também é monitorado, com limites definidos para o tempo que uma resolução difícil real leva, em vez de um limite genérico que seria disparado a cada sucesso.

Novo

Escolha um perfil de navegador por request

O parâmetro profile informa ao desbloqueador com qual navegador se parecer em /api/single e /api/proxy. Passe um id de perfil exato (como firefox147 ou chrome146), ou deixe que browser + os + version resolva para a combinação correspondente mais recente. GET /api/profiles retorna o catálogo atual (79 perfis em cinco famílias de navegadores), para que você não faça hardcode de uma lista que fica obsoleta. O playground do Dashboard expõe o mesmo seletor como três selects em cascata.

Melhoria

Playground seleciona navegador, OS e versão

O Dashboard Playground agora possui três seletores em cascata para OS, navegador e versão, extraídos em tempo real do catálogo de perfis. Selecione dois e o terceiro será restrito ao que realmente é válido. Escolher um perfil ativa unblocker, pois a API recusa um perfil sem ele.

Corrigido

A página de status interpreta rolling deploys corretamente

Um serviço agora é considerado inativo apenas quando perde todas as instâncias, o único estado onde seu request não tem para onde ir. Rolling deploys de rotina não aparecem mais como incidentes na página de status.

Melhoria

A assinatura padrão do desbloqueador está atualizada novamente

A assinatura padrão que o desbloqueador envia agora é uma versão principal atual, não a antiga fixada no código por scrapers. Sites que começaram a retornar páginas de bloqueio estáticas para versões principais mais antigas retornam sua página real no Single e no Browser. Ambos os produtos foram atualizados juntos, para que um replay cf_clearance do Browser para o Single ainda chegue byte a byte.

Corrigido

Alterações de plano concluem a etapa de 3D Secure

Quando o seu banco solicitava o 3D Secure em um upgrade de plano, a request fazia polling por uma alteração que nunca chegava (ninguém havia solicitado que você se autenticasse). O fluxo de alteração de plano agora processa a etapa extra da mesma forma que a primeira assinatura, para que o upgrade seja concluído.

Novo

Planos personalizados aparecem na sua aba Faturamento

Se um administrador atribuir a você um plano personalizado, ele agora aparecerá em Faturamento / Plano como 'Seu plano personalizado: {name} ({price})' com um botão para assinar. Antes disso, a atribuição ficava invisível até que alguém dissesse que ela existia.

Melhoria

Browser cobra créditos por todas as defesas superadas, não apenas Cloudflare

O Browser costumava cobrar o nível de 30 créditos por defesa resolvida apenas quando um cookie de liberação do Cloudflare aparecia. Agora ele faz o mesmo para qualquer defesa que reconhecemos e superamos, começando pelo SiteGround. A resposta também contém defenses: { present, cleared }, para que você possa identificar qual fornecedor estava no caminho, mesmo quando ainda não o superamos (DataDome, PerimeterX, Akamai, Incapsula e hCaptcha são reconhecidos por enquanto, mas ainda não superados).

Melhoria

A resposta do navegador lista todas as defesas presentes e superadas

As respostas do navegador agora retornam defenses: { present, cleared }: cada vendor que o alvo executou e cada um que nós realmente superamos. O faturamento segue a mesma regra. Um request que supera qualquer vendor (não apenas a Cloudflare) é uma resolução de defesa, e os vendors que reconhecemos mas ainda não conseguimos vencer aparecem em present e nunca aumentam o preço.

Novo

Single resolve desafios do SiteGround sem um navegador

O SiteGround atua como front-end para uma grande parte de pequenas lojas WordPress e WooCommerce, portanto sua Robot Challenge Screen é uma classe de alvos, não apenas um site. Com unblocker: true, o Single agora resolve isso no próprio processo e retorna a página real. Antes disso, você precisava iniciar o Browser para essa classe de alvo, o que significava pagar por uma sessão de navegador e pelo tempo de espera. O cookie de clearance volta na response, de modo que um replay continua barato.

Corrigido

Browser lida com interstitials que redirecionam para fora

O browser agora lida com uma página de desafio que redireciona antes que seu corpo possa ser lido, assim as requests para sites protegidos retornam com conteúdo em vez de uma response vazia.

Novo

Single resolve o Robot Challenge da SiteGround

A SiteGround coloca uma 'Robot Challenge Screen' na frente de muitas lojas pequenas de WordPress e WooCommerce; não há nada para clicar, é uma prova de trabalho SHA-1. O Single agora resolve isso em uma chamada e retorna a página real, por 2 créditos em vez de uma sessão de navegador de 30 créditos. É a primeira defesa não Cloudflare que o Single lida por conta própria.