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.
أود فقط أن أضيف دعمي (+1) للسماح باستخدام النقاط في أسماء سلات S3 داخل Discourse. تسمح AWS بذلك (بل وتوجه إلى ذلك هنا) حاليًا للوصول إلى محتوى S3 القائم على أسماء النطاقات المخصصة (CNAME)، وبشرط استخدام إعداد s3_cdn_url في Discourse، فإن المشاكل السابقة المتعلقة بـ HTTPS أصبحت غير مؤثرة، على الأقل عند استخدام خدمات مثل Cloudflare (كما يشير @uppfinnarn إلى أن شهادات SSL القائمة على SNI تحل هذه المشكلة).
هل من الممكن إعادة النظر في هذا الأمر في إصدار قادم؟
مرحبًا رافائيل، ما لم أكن أفتقد شيئًا، فبينما يسمح هذا المعلمة لمنصة Discourse بالاسترجاع من عنوان URL لـ CDN، إذا لم نتمكن من تحديد اسم سلة S3 يحتوي على نقاط، فهل يعني ذلك أننا لا نستطيع فعليًا التحميل إلى تلك السلال؟ هذا يستدعي حلولًا مؤقتة معقدة مثل إعداد أسماء CNAME بديلة في خدمات طرف ثالث إضافية غير مجانية مثل CloudFront (والتي لا نستخدمها حاليًا على الإطلاق، ونفضل عدم استخدامها).
إذا سمحنا بحاويات تحتوي على نقاط، فيجب إضافة إعداد يتيح لك تعطيل التحقق من شهادة SSL عند الاتصال، أو على المستخدمين الذين يستخدمونها إضافة وكيل يضيف طبقة SSL بين Discourse ونقطة نهاية S3، لكنه سيبقى اتصالاً غير مشفر (HTTP عادي) بين الوكيل ونقطة نهاية S3.
إذن لا تستخدمون HTTPS … على الإطلاق؟ هذا هو السبب الرئيسي وفقًا لما سبق.
مرحبًا جيف، نحن نستخدم HTTPS عبر Cloudflare.
إذا سمحنا بـ buckets تحتوي على نقاط، فيجب علينا إضافة إعداد لتمكين تعطيل التحقق من SSL عند الاتصال، أو يجب على المستخدمين الذين يستخدمونها إضافة وكيل يضيف SSL بين Discourse ونقطة نهاية S3، لكن سيبقى الاتصال بين الوكيل ونقطة نهاية S3 عبر HTTP عادي.
أنا متأكد تقريبًا أن Cloudflare ستلتقط هذا وتتعامل معه تلقائيًا دون الحاجة لإضافة إعداد إضافي (إنه نهج استخدمناه سابقًا مع خدمات أخرى).
أقدر تمامًا رغبتكم في تحذير المستخدمين من استخدام اصطلاح تعتبرونه إشكاليًا، لكن نظرًا لأن أسماء buckets S3 الصالحة يمكن أن تحتوي على نقاط (وتوصي وثائق AWS باستخدامها في مجموعة من السيناريوهات)، هل تعتقدون أن هذا شيء قد تفكرون في تمكينه في المستقبل؟
ما البديل؟ فقط أنشئ حاوية S3 جديدة بدون نقاط فيها. لا يوجد سبب يمكنني التفكير فيه لاستخدام حاوية موجودة لملفات Discourse التي تقوم برفعها. هذا حتى يسهل المحاسبة لأنه لا توجد كائنات عشوائية غير تابعة لـ Discourse هناك.
