Destaques
A seleção de perfil de navegador agora é um controle por request. Defina o navegador e o SO desejados, e o fingerprint e os headers refletirão a mesma configuração. O Single aprendeu a concluir mais duas verificações esta semana (as verificações computacionais da SiteGround e do eBay) sem precisar inicializar o Browser. E a visualização Activity do Dashboard agora registra o que você solicitou, não a infraestrutura interna executada por baixo.
O que há de novo
Escolha seu perfil de navegador por request
Até agora, o unblocker: true selecionava uma única assinatura (qualquer que fosse o nosso padrão no momento) e pronto. Agora você pode definir uma:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
ou solicite um par de navegador e sistema operacional:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
A API rejeita combinacoes desconhecidas por nome e lista o que ESTA disponivel, evitando que um erro de digitacao envie silenciosamente uma assinatura que voce nao pediu.
O catalogo completo fica em GET /api/profiles. Ele e publico (nao requer chave), pois e uma lista de recursos, nao um segredo. No momento em que este texto foi escrito, existem 79 presets para Chrome, Firefox, Edge, Safari e Tor, no Windows, macOS, Android e iOS. O Playground le dessa mesma lista, entao o menu suspenso sempre mostra exatamente o que seu codigo pode solicitar.
Por que isso importa: se o seu alvo faz profiling de requisicoes por sistema operacional, ou se a sua equipe esta fazendo testes A/B para ver qual stack passa por um bloqueio especifico, agora voce mantem essa variavel constante enquanto todo o resto muda.
Single conclui as verificacoes computacionais do SiteGround e do eBay
Duas defesas que antes exigiam o redirecionamento pelo Browser agora sao resolvidas no Single. O eBay usa seu proprio desafio de prova de trabalho (um puzzle Argon2) e o SiteGround executa sua propria verificacao em boa parte da web de hospedagem compartilhada. Ambas sao resolvidas sem renderizacao, o que significa que a resposta retorna no formato de uma unica requisicao HTTP e e cobrada de acordo.
O sinal de defesa nas respostas tambem aumentou. As respostas do Browser agora trazem defenses: { present, cleared }, permitindo que voce veja qual fornecedor estava na frente da pagina e se conseguimos passar. O faturamento segue a mesma regra: qualquer fornecedor que superamos e contabilizado, independentemente da marca. Antes dessa janela, apenas um servico de verificacao era cobrado como pagina interativa. Mais tres agora estao ao lado dele.
Visualizacao de atividade reconstruida no Dashboard
Duas colunas na lista de Atividade do Dashboard estavam exibindo dados incorretos. O metodo HTTP sempre mostrava POST em todas as linhas (todos os nossos endpoints sao POST, entao a coluna era uma constante que nao informava nada). Alem disso, o IP do cliente nas chamadas do Playground registrava de onde o Playground chamava, e nao a pessoa clicando em Run.
Ambos foram corrigidos. A coluna de metodo agora exibe o verbo que voce enviou no corpo da requisicao. O IP do cliente nas linhas do Playground agora le o IP do navegador do usuario conectado, transportado em um token assinado do Playground para que um cliente da API nao possa forja-lo.
O restante da visualizacao foi reconstruido durante o processo. A tabela cabe em um notebook sem ocultar colunas, a coluna do produto se integra a linha da requisicao e o painel de detalhes ganhou abas para que a requisicao, a resposta e o resumo da defesa tenham sua propria barra de rolagem.
Faturamento: 3D Secure na alteracao de plano
Se o emissor do seu cartao exigisse uma confirmacao 3DS para uma mudanca de plano (e nao apenas na assinatura inicial), essa etapa nao era acionada e a alteracao sofria rollback silenciosamente. Agora ela e acionada. Se voce tentou mudar de plano no ultimo mes e pareceu que nada aconteceu, foi por isso.
Por baixo do capo
O Playground se recusa a construir um header de resposta a partir dos dados de um site coletado (uma classe de bug de injecao de header que detectamos cedo). Um endpoint de faturamento no Dashboard verifica se quem fez a chamada e dono do recurso antes de responder, fechando um vetor de IDOR.
O próprio pipeline de deploy recebeu uma semana intensa de correções após uma interrupção no dia 6 encher o disco do host de deploy no meio de um build. Todos os serviços agora recusam o build sem espaço livre em disco, os deploys são serializados em vez de disputarem recursos, o gateway permanece ativo quando um backend oscila, e os serviços realmente finalizam com SIGTERM em vez de travarem até serem mortos trinta segundos depois.
Por muito tempo, a escolha de "qual assinatura de navegador usar" era uma decisão nossa tomada por você. Não precisa mais ser assim.