Le miniature delle chat aggirano s3_cdn_url e usano URL raw del bucket S3

Lilly · 31 Maggio 2026, 10:13pm

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.

screenshot

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:

https://github.com/discourse/discourse/pull/40419

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.

https://github.com/Lillinator/chat-s3-thumbnails-fix

~~(non so perché i onebox di GitHub siano rotti qui)~~ Corretto ora

sam · 1 Giugno 2026, 3:09am

Probabilmente legato allo spostamento del sito… l’ho appena rigenerata.

David_Ghost · 11 Giugno 2026, 3:02pm

Ciao, la PR è già stata unita?

Grazie

Lilly · 11 Giugno 2026, 6:31pm

ora è in attesa di revisione da parte di un membro del team umano, dopo che il mio amico discourse-triage-bot ha corretto alcuni test

https://github.com/discourse/discourse/pull/40419#issuecomment-4683409099

Lilly · 15 Giugno 2026, 6:24pm

sembra che sia stato unito ora.

darkpixlz · 16 Giugno 2026, 11:00pm

aperto su richiesta dell’autore

Lilly · 16 Giugno 2026, 11:10pm

Per i siti con emoji personalizzate aggiunte, ora risulteranno non funzionanti in chat una volta che la correzione è stata incorporata.

A differenza delle immagini standard dei post (che possono essere risolte con rake posts:rebake), le emoji personalizzate della chat vengono trasmesse al frontend in modo dinamico tramite /site.json.

Se il tuo database contiene URL S3 che mancano del protocollo (ad esempio //bucket.endpoint...) o utilizzano un dominio in stile virtual-hosted che non corrisponde perfettamente alle variabili di ambiente di app.yml, il sostituto CDN interno di Discourse fallisce silenziosamente. L’URL grezzo del bucket viene inviato al browser, causando il malfunzionamento delle emoji personalizzate in chat.

Come risolvere:

Per risolvere definitivamente il problema, è necessario mappare forzatamente gli URL grezzi del bucket agli URL del CDN nel database, quindi svuotare la cache del sito in modo che /site.json venga rigenerato.

1. Accedere al container:

Effettua SSH sul tuo server ed entra nel container di Discourse (solitamente app, o web_only se hai una configurazione a due container).

cd /var/discourse
./launcher enter app

2. Rimappare gli URL:

esegui lo strumento integrato di Discourse remap. Dovresti eseguirlo due volte per intercettare sia la variante https:// sia la variante senza schema // che lo script di migrazione a volte lascia in sospeso.

Sostituisci i segnaposto con il tuo effettivo URL grezzo del bucket e il tuo effettivo URL del CDN:

# Correggi gli URL standard https://
discourse remap "https://<your-bucket>.<your-endpoint>.com" "https://cdn.your-domain.com"

# Correggi gli URL senza schema // (questo è quello che di solito rompe le emoji personalizzate)
discourse remap "//<your-bucket>.<your-endpoint>.com" "https://cdn.your-domain.com"

3. Svuotare la cache

Poiché /site.json è fortemente memorizzato nella cache, è necessario svuotare la cache di Rails per forzare il forum a servire i nuovi URL:

Apri la console di Rails:

rails c

Esegui questi comandi:

Rails.cache.clear
Site.clear_cache
exit

4. Aggiornare

Esegui un aggiornamento forzato del browser (e disabilita la soluzione alternativa del componente tema se la stai ancora utilizzando). Le emoji personalizzate in chat dovrebbero ora essere funzionanti e caricarsi correttamente tramite il CDN.

David_Ghost · 19 Giugno 2026, 2:33pm

Ciao Lilly, ti ringrazio molto per il tuo ottimo lavoro. Dopo i due rimappaggi, ora i miei vecchi upload e le miniature funzionano come previsto. Prima di allora, non funzionavano nemmeno le immagini di “/admin/config/customize/themes”. Ora è tutto a posto. Fantastico.