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.
Ich wollte nur mein +1 dafür geben, Punkte in S3-Bucket-Namen innerhalb von Discourse zu erlauben. AWS selbst erlaubt dies (und weist sogar darauf hin) mittlerweile für den CNAME-basierten Zugriff auf S3-Inhalte. Solange die Einstellung s3_cdn_url in Discourse genutzt wird, sind die bisher bekannten Probleme im Zusammenhang mit HTTPS meiner Kenntnis nach nicht mehr relevant – zumindest bei der Nutzung von Diensten wie Cloudflare (wie @uppfinnarn anmerkt, lösen SNI-basierte SSL-Zertifikate dieses Problem).
Wäre es möglich, dies in einem zukünftigen Release erneut zu prüfen?
Hallo Rafael, soweit ich das übersehe: Obwohl dieser Parameter es Discourse erlaubt, von einer CDN-URL zu ziehen, können wir keine S3-Buckets mit Punkten im Namen angeben. Können wir also tatsächlich nicht in diese Buckets hochladen? Das erfordert umständliche Workarounds wie das Einrichten alternativer CNAMEs in zusätzlichen, nicht-kostenlosen Diensten Dritter wie CloudFront (den wir derzeit überhaupt nicht nutzen und auch nicht nutzen möchten).
Wenn wir Buckets mit Punkten zulassen, müssen wir eine Einstellung hinzufügen, mit der Sie die SSL-Verifizierung beim Verbinden deaktivieren können, oder Nutzer müssen einen Proxy hinzufügen, der zwischen Discourse und dem S3-Endpunkt SSL hinzufügt, aber zwischen dem Proxy und dem S3-Endpunkt bleibt es weiterhin reines HTTP.
Also verwenden Sie HTTPS … überhaupt nicht? Das ist der Hauptgrund, wie oben erwähnt.
Hallo Jeff, wir verwenden HTTPS über Cloudflare.
Wenn wir Buckets mit Punkten zulassen, müssen wir eine Einstellung hinzufügen, mit der Sie die SSL-Verifizierung bei der Verbindung deaktivieren können. Andernfalls müssen Nutzer einen Proxy verwenden, der SSL zwischen Discourse und dem S3-Endpunkt hinzufügt, aber die Verbindung zwischen dem Proxy und dem S3-Endpunkt bleibt dann weiterhin unverschlüsselt (HTTP).
Ich bin mir ziemlich sicher, dass Cloudflare dies automatisch erkennt und verarbeitet, ohne dass eine zusätzliche Einstellung erforderlich wäre (dieser Ansatz wurde von uns bereits bei anderen Diensten genutzt).
Ich kann absolut verstehen, dass Sie Nutzer vor einer Konvention warnen möchten, die Sie für problematisch halten. Da gültige S3-Bucket-Namen jedoch Punkte enthalten können (und AWS-Dokumentationen empfehlen, diese in einer Reihe von Szenarien zu verwenden), würden Sie dies vielleicht in Zukunft in Betracht ziehen, zu aktivieren?
Welche Alternative? Erstellen Sie einfach einen neuen S3-Bucket ohne Punkte. Mir fällt kein Grund ein, einen bestehenden Bucket für Ihre Discourse-Uploads zu verwenden. Das erleichtert sogar die Abrechnung, da sich keine zufälligen, nicht zu Discourse gehörenden Objekte darin befinden.
Das CloudFront CDN ist optional. Du könntest jedes andere CDN verwenden, das du möchtest, mit einem Bucket-Namen ohne Punkte, und hättest dann auch keine HTTPS-Probleme.
Außerdem ist dieses Bild das Einzige, was mir beim Lesen dieses Austauschs in den Sinn kommt.
(Warnung: Jeder, der eine aktuelle US-Sicherheitsgenehmigung besitzt, sollte das Bild hier nicht veröffentlichen.)
