- Spegnimento
- 6 agosto 2026 alle ore 13:06 UTC
- Autore
- kamo
- Impegno
- a7352ef
Le immagini esterne hanno smesso di rendering quando la politica dell'immagine a livello di pagina è stata spedita. The middleware imposta `img-src 'self' dati: blob: https://theme. https://*. e un corpo e-mail rende in un `srcdoc` iframe con `allow-same-origin`, quindi eredita tale politica — ogni URL di terze parti nel messaggio è stato rifiutato dal browser. "Display immagini esterne" ha rivelato URL che la pagina non è stata consentita caricare, quindi cliccare non ha fatto niente. Il resto dell'app è stato spostato su `/api/images/proxy` nello stesso cambiamento, che è perché `'self'`` è sufficiente ovunque altro. I corpi e-mail erano la superficie emette ancora origini crude. Ora passano attraverso lo stesso proxy, per ` e per `url()` remoto in CSS — `img-src` governa `immagine di sfondo` troppo. Due dettagli sono arrivati: - DOMPurify rivaluta un attributo dopo che un gancio lo riscrive, e un <img> a sinistra senza src è caduto verso l'esterno piuttosto che tenuto come immagine rotta. Quindi... ALLOWED URI REGEXP ha dovuto nominare anche il percorso proxy; senza di esso la riscrittura cancellato le immagini stesse che stava cercando di ripristinare. - `http:` le immagini sono calate piuttosto che proxied. Il proxy parla solo https e una pagina https blocca il contenuto misto indipendentemente, quindi la consegna del browser un URL esso sta per rifiutare aiuta nessuno. Il blocco è invariato mentre il membro non ha consentito le immagini: il trasparente pixel e data-kamo-blocked-src sono ancora in piedi, e nessuna richiesta incendi. In linea cid: le immagini non sono mai state colpite — hanno già risolto ad un percorso di origine la politica permette.