Quando si utilizza S3 o Cloudflare R2 per i upload insieme a un URL CDN personalizzato, gli upload di emoji personalizzate non rispettano la configurazione del CDN e tentano di caricarsi direttamente dall’URL grezzo del bucket.
Il problema
Quando un amministratore carica un’emoji personalizzata, il sistema di upload crea un record upload e salva l’URL grezzo del bucket nel database (ad esempio //my-bucket.s3.amazonaws.com/... o //my-bucket.r2.cloudflarestorage.com/...) — questo è il comportamento standard di Discourse.
Tuttavia, quando app/models/emoji.rb genera la cache delle emoji per /site.json, passa l’upload.url direttamente all’oggetto emoji:
e.url = emoji.upload&.url
Poiché viene saltato l’helper del CDN, il frontend riceve l’URL grezzo del bucket. Di conseguenza, a seconda di quanto restrittive siano le politiche di accesso del bucket, ciò provoca immagini rotte o costringe Discourse a instradare le emoji attraverso il proxy interno avatar_proxy.
Soluzione
Ho aperto una PR che avvolge le assegnazioni degli URL in Discourse.store.cdn_url(), allineando il caricatore di emoji personalizzate al modo in cui vengono instradate le immagini standard dei post e gli avatar.
Soluzione temporanea
Mentre si attende che la PR venga revisionata e unita al codice principale, ho creato un componente tema leggero che sostituisce l’URL grezzo del bucket con il corretto URL CDN proprio prima che l’emoji personalizzata venga renderizzata nel DOM (funziona sia per i post che per la chat).
Se stai riscontrando questo bug sul tuo sito, puoi installare questo componente e configurare le tue stringhe S3 nelle impostazioni dell’amministratore del tema per correggere le emoji personalizzate rotte:
Nota: se hai già caricato emoji personalizzate che sono attualmente rotte, eseguendo discourse remap "//my-raw-bucket-url.com" "https://my-cdn.com" nel container correggerai quelle vecchie nel database, mentre il componente tema correggerà quelle caricate successivamente fino a quando la correzione della PR non verrà integrata nel codice principale.
sì, forse è solo una cosa legata a Cloudflare R2. si stanno bloccando sulla mia istanza. sembra che si blocchino solo per quelli appena caricati.
senza la correzione del componente del tema, devo eseguire il rimappaggio ogni volta che ne carico uno nuovo. la PR potrebbe aver bisogno di qualche ritocco - non sono molto bravo con il codice delle emoji.
Discourse utilizza una configurazione con due CDN, uno per le risorse (assets) e uno che funge da proxy per l’applicazione.
Gli emoji standard utilizzano un CDN, mentre gli emoji personalizzati utilizzano l’altro CDN, ma entrambi sono protetti da un CDN in un sito web configurato correttamente con una configurazione a due CDN funzionante.
Ne ho parlato in dettaglio nel primo argomento correlato qui:
Il tuo sito ha entrambi i CDN configurati e funzionanti?
Le ho impostate, ma per l’amore del cielo, avevo un errore di battitura nella mia configurazione Cloudflare per il record DNS specifico del CDN a cui punta DISCOURSE_CDN_URL e non l’ho mai testato quando l’ho impostato perché il mio sito funzionava che pasticcio.
Almeno ho imparato di più sulla creazione di codici emoji con quella PR inutile…
wow, che giro pazzesco. ho praticamente riconfigurato tutto il mio storage oggetto Cloudflare R2 e l’istanza di Discourse, e penso che questo bug sia legittimo per R2. quando ho corretto il record DNS di Cloudflare e ricostruito l’istanza in modo che DISCOURSE_CDN_URL puntasse effettivamente a esso, ha rotto un sacco di altre cose come le stringhe di traduzione e ha generato diversi errori nella console, inclusi alcuni errori CORS. mi ha portato in molti vicoli ciechi oggi. quindi immagino che usare DISCOURSE_CDN_URL sia incompatibile con Cloudflare R2. (questa era una cosa molto strana - quando ho configurato originariamente il mio record DNS, avevo inserito erroneamente il record DNS cdn.mysite.com in modo che risolvesse come cdn.mysite.com.mysite.com). impostare correttamente DISCOURSE_CDN_URL sembra incompatibile con lo storage oggetto Cloudflare R2. potrebbe esserci qualcos’altro che non capisco del tutto qui.
comunque, quando ricostruisco con il mio ramo PR, tutto è risolto perché avvolge l’assegnazione in Discourse.store.cdn_url() in modo che gli upload di emoji personalizzate rispettino la stessa logica di routing e fallback CDN S3 degli upload standard di immagini dei post.
ho riaperto la PR e modificato la descrizione. ma immagino che se il team di Discourse decide di non unirla, va bene così, perché il componente del tema risolve il problema a livello client. nota che la correzione della PR dovrebbe influenzare solo le configurazioni di storage oggetto R2 per le emoji personalizzate e non altri storage compatibili S3 come AWS.
Questa PR è stata unita e le emoji personalizzate sono ora corrette quando si utilizza lo storage oggetto Cloudflare R2 per i caricamenti. Ho pubblicato un suggerimento di aggiornamento alla documentazione R2 pertinente qui: Configure an S3 compatible object storage provider for uploads
che pasticcio.