So, with the introduction of the s3_cdn_url setting, you can set a custom URL to be used instead of the long S3 URL.
Unfortunately, s3_upload_bucket doesn’t allow periods in the name… which means that if I, as per Amazon’s documentation, create a bucket called static.example.com and point a CNAME to it, I can set Discourse to print out URLs to static.example.com, but I can’t set it to actually upload to that bucket.
(I want to put Cloudflare in front of a CNAME, making for a low-cost but effective CDN. It’s not just for looks.)
As I understood it, periods in the bucket name cause havoc with https and certificates so it is strongly discouraged that you do this. Unless you never plan to use https.
This is a good point. However, I think it should be downgraded to a warning, rather than being outright forbidden.
While locking yourself out of HTTPS is a terrible idea on its own, both Amazon CloudFront and CloudFlare (off the top of my head) offer SNI-based SSL certificates that can be put in front of a bucket, even if the default certificate would no longer cover it.
CloudFront can be configured to pull from an S3 bucket of your choice (even if it’s named something different), but also costs money. Well invested money, one may argue, but money nonetheless. If one does not need the additional functionality of a full-fledged CDN, CloudFront is a slightly overkill solution to the problem of “I want my forum to load faster”.
(An incredibly convoluted pricing model doesn’t help… I think there’s an XKCD for this, but I can’t find it.)
CloudFlare is not as configurable, but also offer quite a few other features as well - as well as the very approachable price tag of free. With a properly named bucket and a DNS rule (possibly supplemented by some caching rules), you get an instant improvement to loading performance, with no downsides whatsoever.
Perhaps not as big of a difference as a full CDN would make, but hey, it’s free performance.
Is there a way to allow periods in the S3 name (may be with a warning for https issue for direct s3 use). This is a showstopper in my case to use S3 with cloudflare and discourse.
@fearlessfrog Thanks…I ended up doing exactly the same. I don’t know how I missed your thread earlier. Just to highlight - this approach has a limitation in terms of cache invalidation. we have to do separately invalidations in cloudfront and cloudflare (after rebaking posts). It would be great to automate them with a script at the very least.
I hit up on the same blocks eventually in terms of optimised image urls and was planning to start a thread today…Nice to know that you have already helped the team towards a fix in the below given thread. Kudos for that.
Volevo solo aggiungere il mio +1 a favore della possibilità di utilizzare punti nei nomi dei bucket S3 all’interno di Discourse. AWS stesso lo consente (anzi, lo consiglia in questo documento) per l’accesso ai contenuti S3 basato su CNAME e, a quanto mi risulta, se viene utilizzata l’impostazione s3_cdn_url in Discourse, i problemi precedenti relativi a HTTPS non sono più un ostacolo, almeno quando si utilizzano servizi come Cloudflare (come osserva @uppfinnarn, i certificati SSL basati su SNI risolvono questo problema).
È possibile riconsiderare questa possibilità in una prossima versione?
Ciao Rafael, a meno che non mi stia sfuggendo qualcosa, anche se quel parametro permette a Discourse di prelevare da un URL CDN, se non possiamo specificare un nome di bucket S3 contenente punti, non potremo effettivamente caricare dati in quei bucket? Questo rende necessari workaround poco eleganti, come la configurazione di CNAME alternativi in servizi di terze parti aggiuntivi e non gratuiti come CloudFront (che al momento non stiamo affatto utilizzando e preferiremmo evitare).
Se permettiamo bucket con punti, dobbiamo aggiungere un’impostazione per disabilitare la verifica SSL durante la connessione, oppure gli utenti dovranno aggiungere un proxy che gestisca l’SSL tra Discourse e l’endpoint S3, ma la comunicazione tra il proxy e l’endpoint S3 rimarrà in HTTP non crittografato.
Quindi non usate affatto HTTPS…? È il motivo principale, come detto sopra.
Ciao Jeff, stiamo utilizzando HTTPS, tramite Cloudflare.
{quote} Se permettiamo bucket con punti, dobbiamo aggiungere un’impostazione per disabilitare la verifica SSL durante la connessione, oppure gli utenti che lo utilizzano devono aggiungere un proxy che aggiunge SSL tra Discourse e l’endpoint S3, ma rimarrà comunque HTTP in chiaro tra il proxy e l’endpoint S3.{/quote}
Sono quasi certo che Cloudflare rileverà e gestirà automaticamente questa situazione senza la necessità di aggiungere un’impostazione aggiuntiva (è un approccio che abbiamo già utilizzato in passato con altri servizi).
Capisco perfettamente il desiderio di scoraggiare gli utenti dall’utilizzare una convenzione che ritieni problematica, ma dato che i nomi validi dei bucket S3 possono contenere punti (e la documentazione AWS ne consiglia l’uso in una serie di scenari), potresti considerare di abilitarlo in futuro?
Quale alternativa? Crea semplicemente un nuovo bucket S3 senza punti al suo interno. Non riesco a pensare a nessun motivo per cui dovresti usare un bucket esistente per i caricamenti di Discourse. Anzi, rende la contabilità più semplice, dato che non ci saranno oggetti casuali non relativi a Discourse all’interno.
Il CDN CloudFront è opzionale. Potresti utilizzare qualsiasi altro CDN con un nome di bucket privo di punti e non avresti nemmeno i problemi relativi all’HTTPS.
Inoltre, questa immagine è l’unica cosa che mi viene in mente mentre leggo questo scambio.
(Attenzione: chiunque sia in possesso di una clearance di sicurezza statunitense vigente non dovrebbe rivelare l'immagine qui.)
