Destaques
A escolha de perfil de navegador agora é configurada por request. Especifique o navegador e o sistema operacional que você deseja, e o fingerprint junto com os headers descreverão a mesma coisa. O Single aprendeu a resolver mais duas defesas esta semana (SG-Captcha do SiteGround e o desafio Argon2 do eBay) sem precisar iniciar o Browser. E a visualização Activity do Dashboard agora registra o que você solicitou, não a infraestrutura que rodou por trás disso.
Novidades
Escolha o perfil do seu navegador por request
Até agora, o unblocker: true escolhia uma assinatura (qualquer que fosse o nosso padrão atual) e era isso. Agora você pode especificar uma:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
ou solicite um par de navegador e OS:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
A API rejeita combinações desconhecidas pelo nome e lista o que ESTÁ disponível, para que um erro de digitação não envie silenciosamente uma assinatura que você nunca pediu.
O catálogo completo está em GET /api/profiles. É público (nenhuma chave é necessária), porque é uma lista de capacidades, não um segredo. No momento em que este texto foi escrito, existem 79 predefinições no Chrome, Firefox, Edge, Safari e Tor, no Windows, macOS, Android e iOS. O Playground lê a mesma lista, então o menu suspenso sempre mostra exatamente o que seu código pode solicitar.
Por que isso importa: se o seu alvo perfila requests por sistema operacional, ou se a sua equipe está fazendo um teste A/B de qual stack passa por um muro específico, agora você mantém essa variável constante enquanto todo o resto muda.
O Single resolve o SG-Captcha e o proof-of-work do eBay
Duas defesas que antes forçavam um redirecionamento pelo Browser agora são resolvidas no Single. O eBay envia seu próprio desafio de proof-of-work (um quebra-cabeça Argon2) e a SiteGround protege uma parte da web de hospedagem compartilhada com o SG-Captcha. Ambos são resolvidos sem renderização, o que significa que o response retorna na forma de um único request HTTP e é cobrado de acordo.
O sinal de defesa nos responses também cresceu. Os responses do Browser agora carregam defenses: { present, cleared }, para que você possa ver qual fornecedor estava na frente da página e se conseguimos passar. O faturamento segue a mesma regra: qualquer fornecedor que passamos recebe atribuição, não importa a marca. A Cloudflare era a única resolução paga antes desta janela. Akamai Bot Manager, SG-Captcha e o desafio do eBay agora estão ao lado dela.
Visão de Activity reconstruída no Dashboard
Duas colunas na lista de Activity do Dashboard estavam mostrando a coisa errada. O método HTTP sempre exibia POST em cada linha (todos os nossos endpoints são POST, então a coluna era uma constante que não dizia nada). E o IP do cliente nas chamadas do Playground registrava de onde o Playground chamou, não a pessoa clicando em Run.
Ambos foram corrigidos. A coluna de método agora lê o verbo que você enviou dentro do corpo do request. O IP do cliente nas linhas do Playground agora lê o IP do navegador do usuário conectado, transportado dentro de um token do Playground assinado para que um cliente da API não possa falsificá-lo.
O restante da visualização foi reconstruído enquanto estávamos lá. A tabela cabe em um laptop sem esconder colunas, a coluna do produto dobra na linha do request, e o painel de detalhes ganhou abas para que o request, o response e o resumo da defesa tenham sua própria rolagem.
Faturamento: 3D Secure na alteração de plano
Se o emissor do seu cartão exigia uma confirmação 3DS para uma alteração de plano (não apenas na assinatura inicial), essa etapa não era acionada e a alteração era silenciosamente revertida. Agora ela é acionada. Se você tentou mudar de plano no último mês e pareceu que nada aconteceu, é por isso.
Sob o Capô
O Playground se recusa a construir um header de response a partir dos dados de um site buscado (uma classe de bug de injeção de header que pegamos cedo). Um endpoint de faturamento no Dashboard verifica se o chamador possui o recurso antes de responder, fechando um caminho IDOR.
O próprio pipeline de deploy recebeu cerca de uma semana de correções após uma interrupção no dia 6 que encheu o disco do host de deploy no meio do build. Cada serviço se recusa a fazer build sem espaço livre em disco, os deploys são serializados em vez de competirem entre si, o gateway continua operando quando um backend oscila, e os serviços realmente são encerrados no SIGTERM em vez de travarem até serem interrompidos trinta segundos depois.
Por muito tempo, "qual assinatura de navegador" era uma decisão nossa feita por você. Não precisa ser assim.