Ho appena configurato un bucket di upload su Cloudflare R2 e le miniature delle chat si sono rotte. Ho quindi fatto un po’ di ricerca e ho applicato una correzione rapida alla mia configurazione, per poi scoprire questo argomento: Cloudflare R2 Image URL Display Issue: Detailed Explanation and Fix. Comunque, ho esaminato altre configurazioni di bucket di upload S3 e ho notato che il problema non era specificamente legato a Cloudflare.
Descrizione
Quando viene configurato un archivio oggetti esterno S3 o compatibile per gli upload, le miniature delle chat bypassano la CDN e vengono caricate direttamente dall’URL del bucket.
Per bucket esterni sicuri compatibili con S3, come Cloudflare R2, le miniature delle chat si rompono e non vengono visualizzate.
Il problema sottostante è che il serializzatore delle chat non riesce ad applicare l’impostazione s3_cdn_url alle miniature. Invece di instradare l’immagine attraverso la CDN configurata, viene esposto direttamente al browser l’URL interno grezzo del bucket S3.
Passaggi per riprodurre
Questo problema è riproducibile su Meta e su altri siti che utilizzano bucket di upload S3:
- Pubblica un’immagine in una chat o in un canale
- Ispeziona l’URL della miniatura nell’console
- Clicca sull’immagine per ottenere la versione originale più grande e ispeziona l’URL
- Confrontalo con quello della miniatura
Ecco un esempio tratto da una chat di Meta
URL della miniatura: dal bucket
https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532_2_375x500.jpeg
URL originale: tramite CDN
https://global.discourse-cdn.com/meta/original/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532.jpeg
Nella console, l’HTML della miniatura <img... contiene data-large-src = URL CDN di CloudFront, e src = URL del bucket AWS.
Impatto:
- Per archivi compatibili con S3 come Cloudflare R2, che sono sicuri per impostazione predefinita e bloccano l’accesso non autenticato agli endpoint grezzi del bucket, le miniature delle chat (ottimizzate) non funzionano.
- Perdite di banda per AWS e altri bucket di archiviazione oggetti compatibili con S3 che consentono l’accesso agli endpoint grezzi del bucket, poiché le chat bypassano completamente la CDN; ciò comporta il pagamento diretto delle tariffe di egress S3 per tutto il traffico delle miniature delle chat.
- Perdita di informazioni sull’infrastruttura: gli URL di archiviazione backend grezzi (inclusi i nomi interni dei bucket e talvolta gli ID account) vengono esposti nei payload JSON del client.
PR:
Ho una PR per risolvere il problema qui:
Sembra che Sam abbia aggiunto getURLWithCDN all’anteprima del compositore delle chat, tuttavia non credo che questo venga applicato al flusso delle chat?
Mi chiedo se la correzione del compositore potesse fallire anche per alcune configurazioni S3, poiché getURLWithCDN va in crash in caso di mismatch del protocollo (// rispetto a https://)? Comunque, la PR sopra citata estende semplicemente il lavoro di Sam aggiungendo i wrapper al flusso e rendendolo agnostico rispetto al protocollo.
Soluzione temporanea:
Prima di capire che si trattava di più di un problema legato a Cloudflare, ho creato un componente tema leggero. Questo intercetta i domini S3 grezzi nel DOM delle Chat e li sostituisce con il dominio CDN corretto prima che il browser tenti di scaricarli. In questo modo il traffico viene instradato correttamente e la perdita di banda viene chiusa. L’ho adattato per funzionare con qualsiasi archivio oggetti compatibile con S3. Sono necessarie solo due impostazioni: URL grezzo del bucket S3 e URL CDN S3.
(non so perché i onebox di GitHub siano rotti qui) Corretto ora