Il mio sito Discourse è ricco di immagini. A causa delle molte immagini, utilizzo una combinazione S3/CDN per archiviare e servire le immagini. All’interno della CDN, utilizzo varie misure per prevenire il dirottamento di immagini. Una delle misure è impedire l’accesso diretto alle immagini e consentire l’accesso solo da un elenco di hostname definito.
Discourse funziona con questa configurazione, ad eccezione degli avatar. Gli avatar smettono di funzionare quando la protezione hotlinking è attiva.
Il motivo è che Discourse utilizza una configurazione proxy per gli avatar. L’HTML utilizza un link proxy per gli avatar. La struttura del link è https://discourse.forum/user_avatar/discourse.forums/username/24/616_2.png.
Una volta risolto il proxy, il browser richiede l’accesso diretto al file immagine.
La mia CDN impedisce l’accesso diretto con un 403 quando viene effettuata questa richiesta diretta. E tutti gli avatar personalizzati diventano sagome.
Quali opzioni abbiamo per rimuovere il proxy?
Possiamo cambiare l’avatar in una struttura di file immagine standard?
Il collegamento di accesso diretto proviene dall’indirizzo IP dell’utente. Il server risolve le informazioni, ma la chiamata viene effettuata dal browser locale.
Non sono sicuro che funzioni in questo modo. A seconda della configurazione, il proxy effettua effettivamente il proxy o la CDN va per prima. Puoi spiegare come è configurato?
Odio le domande vaghe. A cosa stavi pensando quando hai chiesto “questo”?
Ecco le mie impostazioni attuali:
Configurazione Discourse:
Installazione standard in un singolo container
Configurato come sottodominio: forums.domain.tld
Configurazione S3 standard per i caricamenti
I caricamenti vengono salvati su S3
Configurazione S3:
Digital Ocean S3 Bucket
Bucket attivato per l’accesso esterno
Nessun altro livello di sicurezza o permessi
Configurazione CDN:
bunny CDN
Riferimenti consentiti impostati: domain.tld e *.domain.tld
L’interruttore che ha causato l’errore di accesso agli avatar è stato “Block Direct URL File Access” (Blocca accesso diretto ai file tramite URL).
Quando attivato, tutti gli avatar hanno ricevuto un errore 403. Quando disattivato, gli avatar vengono visualizzati.
Immagini non Avatar:
URL in Discourse: https://cdn.domain.tld/optimized/3X/3/1/filename_#_size.jpeg
Immagini Avatar:
URL in Discourse: https://forums.domain.tld/user_avatar/forums.domain.tld/mazzini/48/776_2.png
Un post precedente, How are avatars stored and accessed?, indica che Discourse utilizza un proxy per gli avatar. Pertanto, la struttura dell’URL per gli avatar non è una struttura URL di immagine standard.
All’interno del mio sistema, gli avatar sono disponibili dall’S3 o dalla CDN. Ciò indica che da qualche parte/in qualche modo l’URL dell’avatar viene convertito in un URL CDN.
Quando ciò accade, la CDN considera l’URL un link di accesso diretto e blocca l’accesso con un 403.
E a me non piace quando le persone rispondono così quando dedico il mio tempo ad aiutarle, quindi siamo pari .
Sì, e “proxy” significa che la richiesta passa attraverso Discourse. La richiesta non viene effettuata dal browser al CDN, ma da Discourse.
Hai configurato il CDN come CDN per l’intero sito o come CDN S3? Sospetto quest’ultimo. E in tal caso la richiesta viene effettuata da Discourse al CDN, senza referrer. Ma il CDN può comunque riconoscere che si tratta di una richiesta legittima perché la richiesta proviene dall’IP di Discourse. Da qui il mio consiglio di metterlo in whitelist.
Modifica: potresti verificarlo disattivando la protezione per un breve periodo e guardando i log in Bunny, e vedere da quale IP provengono.
Apprezzo il tuo aiuto. Dopo decenni di lavoro nello sviluppo e nel supporto IT, domande e risposte vaghe creano più lavoro del necessario. Sulla base della tua esperienza, penso che saresti d’accordo.
La CDN è configurata solo per il bucket S3.
Ho controllato i log della CDN per l’IP di Discourse relativo agli errori 403 prima di inviare l’argomento originale. Non era nei file di log.
Sulla base dei tuoi commenti, sono tornato indietro e ho rianalizzato i log. Dopo aver esaminato i principali trasgressori IP, ho scoperto che un paio di quelli in cima sono gateway per la società di hosting.
La sfida è che non voglio tenere traccia degli indirizzi IP gateway di Digital Ocean in modo che il mio server Discourse possa visualizzare correttamente le immagini.
.