S3 buckets containing periods not allowed

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.)

「いいね!」 2

If periods are indeed supported we should relax the restriction … @techAPJ can you have a quick look

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.

http://shlomoswidler.com/2009/08/amazon-s3-gotcha-using-virtual-host.html

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.

「いいね!」 5

aha … well then let’s just leave it as is for now.

「いいね!」 1

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.

「いいね!」 3

@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

http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html#VirtualHostingCustomURLs

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.

Thanks

「いいね!」 2

We worked around that here @gingerman :

「いいね!」 5

@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.

「いいね!」 2

S3 バケット名にピリオドを含めることを Discourse で許可することへの賛成票を投じたいと思います。AWS 自体が、CNAME ベースの S3 コンテンツアクセスに対してこれを許可(むしろ推奨)しています(参考)。Discourse の s3_cdn_url 設定が使用されている限り、私が知る限り、以前 HTTPS 周りで発生していた問題は、少なくとも Cloudflare のようなサービスを使用する場合には解決されます(@uppfinnarn が指摘している通り、SNI ベースの SSL 証明書がこの問題を解決します)。

今後のリリースでこの件を見直すことは可能でしょうか?

素晴らしい製品をありがとうございます!

S3_CDN_URL はすでに任意の値に設定できるため、これを許可することでどのようなメリットが得られるのでしょうか?

こんにちは、ラファエルさん。何か見落としているかもしれませんが、そのパラメータは Discourse が CDN URL からデータを取得できるようにするものの、S3 バケット名にドットを含めることができない場合、実際にはそのバケットへのアップロードはできないのでしょうか?この場合、CloudFront のような追加の非無料のサードパーティサービスで代替 CNAME を設定するといった、厄介な回避策が必要になります(現時点では CloudFront は全く使用しておらず、使用したくもありません)。

(結局のところ、有効な S3 バケット名であるものを一律に拒否したいと思う理由が私には理解できません!)

つまり、https を全く使用していないのですか?それが上記の主な理由です。

「いいね!」 1

ここでトレードオフが何か理解できません。

ドットを含むバケットを許可する場合、接続時に SSL 検証を無効化できる設定を追加する必要があります。あるいは、ユーザーが Discourse と S3 エンドポイントの間に SSL を追加するプロキシを導入する必要がありますが、その場合でもプロキシと S3 エンドポイントの間は平文の HTTP になります。

すべてを考慮した上で、そのメリットは何でしょうか?

「いいね!」 1

つまり、https を全く使用していないのですか?それが上記の主な理由です。

こんにちは、Jeff さん。私たちは Cloudflare を介して HTTPS を使用しています。

バケット名にドットを許可する場合、接続時に SSL 検証を無効化する設定を追加する必要があります。あるいは、Discourse と S3 エンドポイントの間に SSL を追加するプロキシを使用する必要がありますが、その場合でもプロキシと S3 エンドポイントの間は平文の HTTP になります。

これは Cloudflare が自動的に検出して処理してくれるはずです。追加の設定は不要でしょう(以前も他のサービスで同様のアプローチを採用したことがあります)。

問題のある慣習だと考えられるため、ユーザーに警告したいというお気持ちは十分理解できます。しかし、有効な S3 バケット名にはピリオドが含まれることがあり、AWS のドキュメントでもさまざまなシナリオでピリオドの使用を推奨していることを考えると、将来的にこれを有効化することを検討していただけませんか?

いいえ、検討はしません。

わかりました、ありがとうございます。修正するか、代替案を見つけるしかないですね :slight_smile:

代替案は?ドットを含まない新しい S3 バケットを作成してください。Discourse のアップロード用に既存のバケットを使用する理由は考えられません。Discourse 以外のオブジェクトが混在しないため、会計処理も簡単になります。

少なくとも、これ よりマシなものが実現できればと思います(少なくとも動作はするはずです)。

[quote=“delta, post:20, topic:35645, full:true”]
この リンク よりは少なくともマシなものであれば(それでも動作するだけでも良いですが)。[/quote]

CloudFront CDN はオプションです。ドットを含まないバケット名を使用すれば、任意の他の CDN を利用することもでき、HTTPS に関する問題も発生しません。

また、そのやり取りを読んでいるときに思い浮かぶのはこの画像だけです。

[details=“(警告:現在米国のセキュリティクリアランスを持っている人は、この画像をここで公開しないでください。)”


[/details]

「いいね!」 2