The discussion revolves around the restriction in Discourse of using periods in S3 bucket names. uppfinnarn initially points out the limitation, citing Amazon’s documentation, which allows periods in bucket names for CNAME-based access.
codinghorror explains that the restriction is due to issues with HTTPS and certificates when using periods in bucket names. However, uppfinnarn and delta argue that using SNI-based SSL certificates, such as those offered by Cloudflare, can mitigate these issues.
gingerman shares their experience of using Cloudflare to access S3 content and requests that the restriction be relaxed. delta and winterdj also express their desire to use S3 bucket names with periods, citing valid use cases.
However, codinghorror ultimately decides that the restriction will not be lifted, citing the potential for HTTPS issues. delta and theblazehen consider alternative solutions, including modifying the database or using a different CDN.
The discussion highlights the trade-offs between restricting S3 bucket names with periods and allowing users to configure their own solutions. Some users suggest that displaying a warning or documentation link could educate users about the potential issues while still allowing them to use bucket names with periods.
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.
We ran into many problems with this, which is why it is disallowed. It is not random. It’s a resolution to a problem many Discourse instances faced.
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.
@codinghorror@sam I am using a cloudflare CDN to access the S3 content (where discourse uploads all the files) and not directly.
s3 mandates to use bucket name like files.discourse.org to access its content through cname files
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.
Discourse에서 S3 버킷 이름에 마침표(.)를 허용하도록 +1을 표합니다. AWS 자체도 CNAME 기반의 S3 콘텐츠 접근에 대해 이를 허용하고 있습니다(실제로 권장하고도 있습니다). 제가 아는 바로는 Discourse의 s3_cdn_url 설정이 활용된다면 이전에 HTTPS와 관련하여 겪었던 문제들은 더 이상 문제가 되지 않을 것입니다. 특히 Cloudflare와 같은 서비스가 사용될 경우 그렇습니다(@uppfinnarn이 언급했듯이 SNI 기반 SSL 인증서는 이 문제를 해결합니다).
라파엘, 안녕하세요. 제가 뭔가 놓치고 있는 게 아니라면, 해당 파라미터가 Discourse가 CDN URL에서 가져오도록 허용하지만, 마침표가 포함된 S3 버킷 이름을 지정할 수 없다면 실제로 해당 버킷에 업로드를 할 수 없는 건가요? 그러면 CloudFront와 같은 추가적인 유료 제3자 서비스에서 대체 CNAME을 설정하는 것과 같은 어색한 우회 방법을 사용해야 하는데, 우리는 현재 CloudFront를 전혀 사용하지 않고 있고, 앞으로도 사용하지 않기를 원합니다.
점(.)이 포함된 버킷을 허용한다면, 연결 시 SSL 인증을 비활성화할 수 있는 설정을 추가해야 합니다. 그렇지 않으면 해당 기능을 사용하는 사람들이 Discourse와 S3 엔드포인트 사이에 SSL을 추가하는 프록시를 구성해야 하는데, 이 경우에도 프록시와 S3 엔드포인트 간 통신은 여전히 평문 HTTP로 이루어집니다.
그래서 https를 전혀 사용하지 않는다는 뜻인가요? 위에서 언급한 대로 이것이 주된 이유입니다.
Jeff님, 저희는 Cloudflare를 통해 HTTPS를 사용하고 있습니다.
만약 점을 포함하는 버킷을 허용한다면, 연결 시 SSL 검증을 비활성화할 수 있는 설정을 추가해야 합니다. 그렇지 않으면 해당 기능을 사용하는 사람들이 Discourse와 S3 엔드포인트 사이에 SSL을 추가하는 프록시를 설정해야 하지만, 이 경우에도 프록시와 S3 엔드포인트 사이의 통신은 여전히 평문 HTTP로 이루어집니다.
Cloudflare가 이를 자동으로 감지하고 처리할 것으로 확신합니다. 추가 설정이 필요하지 않으며, 이전에도 다른 서비스에서 동일한 방식을 사용했던 경험이 있습니다.
문제가 있다고 판단되는 관례의 사용을 사용자에게 경고하고 싶은 마음은 충분히 이해합니다. 하지만 유효한 S3 버킷 이름에 마침표가 포함될 수 있으며(AWS 문서에서도 다양한 시나리오에서 이를 사용할 것을 권장하고 있습니다), 향후 이를 활성화하는 방안을 고려해 주실 수 있을까요?
