feat(scripts): verifica a instalação de web push num site de fora

[daniloleonecarneiro]

Summary

Adiciona scripts/verify-web-push-install.sh, que roda o checklist de aceite de uma instalação de web push contra um site, de fora. Web push depende de dois artefatos no lado do cliente e meia instalação não falha de forma visível: o site simplesmente nunca capta assinatura, e nada no BMS indica isso. Conferir à mão exige abrir o site, o DevTools e comparar hashes na unha — lento e fácil de errar logo depois de um deploy, que é exatamente quando importa.

Changes

• scripts/verify-web-push-install.sh, com seis verificações: sw.js responde 200 na raiz; content-type é de JavaScript; não houve redirect para subpasta (o escopo do service worker não sobe de diretório); o importScripts aponta para uma URL /bms/push/<accountHash>.js; esse hash é o da conta esperada, quando --account é passado; o worker referenciado resolve 200; e a página carrega bmsTrkOptions, o bmstrk.js e o mesmo hash, quando --page é passado.
• Sai 0 quando tudo passa e 1 na primeira falha real, então serve tanto para conferência manual quanto para amarrar num passo de deploy. Sem --account ou --page o script avisa que aquela verificação não foi feita, em vez de passar calado.

Type of change

• Bug fix (fix:)
• New feature (feat:)
• Refactor (refactor:)
• Docs only (docs:)
• Tooling / chore (chore:)
• Breaking change

Testing

Exercitado ponta a ponta contra um site falso servido por python3 -m http.server, apontando para uma instalação local real do BMS — o importScripts do caso feliz resolve num worker que a API de fato serve.

Caso feliz: seis verificações verdes, exit 0.

Casos de falha, cada um verificado individualmente:

• sw.js ausente — falha e interrompe, já que o resto depende do arquivo; exit 1.
• sw.js que não é um shim (sem importScripts) — falha apontando isso.
• hash de outra conta — falha mostrando o hash esperado para a conta passada.
• hash inexistente — falha porque o worker no BMS responde 404.
• página sem snippet — falha em bmsTrkOptions e bmstrk.js.

Na primeira versão a página sem snippet acusava também "accountHash diverge", o que sugeria conta errada quando o problema era ausência do snippet. A comparação de hash agora só roda quando há snippet.

• pnpm type-check passes
• pnpm lint passes
• pnpm test passes
• Manually verified the change end-to-end (descrito acima)

Não se aplicam ao script: prettier não infere parser para .sh e o hook do repo usa --ignore-unknown. Rodei bash -n, que passa. Não consegui rodar shellcheck — não está instalado no ambiente; vale um olhar de quem tiver.

Screenshots

Não se aplica.

Notes for reviewers

O script assume o formato de shim de duas linhas que a UI gera em Configurações → Push. Se o formato mudar, a extração do importScripts é o primeiro ponto a ajustar.

A verificação de raiz compara a URL final depois de seguir redirects. Um site que responda sw.js na raiz via rewrite interno (sem redirect HTTP) passa, o que é o comportamento correto — o que quebra o escopo é o navegador receber o arquivo de outro caminho, não a origem interna dele.

[filipecrosk]

Requesting changes before merge.

1. Page validation uses independent whole-document substring searches. A stale/commented snippet or unrelated text containing bmsTrkOptions, bmstrk.js, and the hash passes while the actual page configuration is broken. Parse/check the actual configuration block and tracker script source.

2. /tmp/sw-verify.$$ is predictable and may be pre-created as a symlink by another local user, allowing curl to overwrite the target with the operators permissions. Use mktemp and a trap cleanup (ideally a private temp directory).

[filipecrosk]

The original substring and predictable-temp-file findings were addressed, and the script passes and ShellCheck. Two failure-path blockers remain:\n\n1. A missing value for or hangs the argument loop. becomes empty, fails because only one argument remains, and without the same option is processed forever. I reproduced still running until an external 2-second alarm killed it (exit 142). Validate that each option has a non-empty following value and exit 2 on bad usage before shifting.\n\n2. is not checked. If /var/folders/bp/g36s8ny94p9520_jtt41dd_c0000gn/T/tmp.S5DkpjWgWZ fails, execution continues with an empty and the first curl targets instead of a private temp file. Abort immediately when temp-directory creation fails, then install the cleanup trap only after success.\n\nPlease add small shell regression coverage for bad option values and temp-creation failure so these paths stay fixed. No GitHub checks are configured.

[filipecrosk]

The original substring and predictable-temp-file findings were addressed, and the script passes bash -n and ShellCheck. Two failure-path blockers remain:

1. A missing value for --account or --page hangs the argument loop. ${2:-} becomes empty, shift 2 fails because only one argument remains, and without set -e the same option is processed forever. I reproduced --account still running until an external 2-second alarm killed it (exit 142). Validate that each option has a non-empty following value and exit 2 on bad usage before shifting.

2. TMPD="$(mktemp -d)" is not checked. If mktemp fails, execution continues with an empty TMPD and the first curl targets /sw.js instead of a private temp file. Abort immediately when temp-directory creation fails, then install the cleanup trap only after success.

Please add small shell regression coverage for bad option values and temp-creation failure so these paths stay fixed. No GitHub checks are configured.