- Navios
- 6 de agosto de 2026 às 13:06 UTC
- Autor
- kamo
- Enviar
- a7352ef
As imagens externas pararam de renderizar quando a política de imagem de nível de página foi enviada. A middleware sets `img-src 'self' data: blob: https://theme.<apex> https://*.<apex>`, e um corpo de e-mail renderiza em um iframe `srcdoc` com `allow-same-origin`, então herda essa política — cada URL de terceiros na mensagem foi recusada pelo browser. "Exibir imagens externas" revelou URLs a página não foi permitida Carregar, por isso clicar não fez nada. O resto do aplicativo foi movido para `/api/images/proxy` na mesma alteração, que É por isso que ''eu'' é suficiente em todos os outros lugares. Os corpos de e-mail eram a superfície ainda emitindo origens cruas. Eles agora passam pelo mesmo proxy, para `<img src>` e para `url()' remoto em CSS — `img-src` também governa `background-image`. Apareceram dois pormenores: - DOMPURIFY re-valida um atributo após um gancho reescrevê-lo, e um <img> esquerda sem src é deixado para fora em vez de mantido como uma imagem quebrada. Então... ALOWED URI REGEXP teve que nomear o caminho do proxy também; sem ele a reescrita apagou as imagens que estava tentando restaurar. - 'http:' imagens são largadas em vez de proxied. O proxy só fala https e uma página https bloqueia conteúdo misto, independentemente, por isso entregando ao navegador um URL vai recusar ajuda ninguém. O bloqueio é inalterado enquanto o membro não permite imagens: a transparente pixel e data-kamo-bloqueado-src ainda estão em pé, e nenhum pedido de fogo. Em linha cid: as imagens nunca foram afetadas — já resolveram um caminho de origem a política permite.