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.
Só queria dar meu +1 para permitir pontos nos nomes de buckets do S3 no Discourse. A própria AWS agora permite (e até instrui) isso para acesso a conteúdo do S3 baseado em CNAME. Desde que a configuração s3_cdn_url no Discourse seja utilizada, os problemas anteriores relacionados ao HTTPS parecem ter sido resolvidos, pelo menos quando serviços como o Cloudflare são usados (como @uppfinnarn observa, certificados SSL baseados em SNI resolvem essa questão).
Seria possível reavaliar isso em uma próxima versão?
Olá Rafael, a menos que eu esteja deixando algo passar: embora esse parâmetro permita que o Discourse busque de uma URL de CDN, se não pudermos especificar um nome de bucket S3 com pontos, não poderemos realmente fazer upload nesses buckets? Isso exige soluções alternativas complicadas, como configurar CNAMEs alternativos em serviços de terceiros adicionais e não gratuitos, como o CloudFront (que não estamos usando de forma alguma no momento e preferiríamos não usar).
(E, acho que no final das contas, eu simplesmente não entendo por que alguém gostaria de rejeitar categoricamente algo que é um nome de bucket S3 válido!)
Se permitirmos buckets com pontos, teremos que adicionar uma configuração para desabilitar a verificação de SSL na conexão, ou os usuários que utilizarem isso precisarão adicionar um proxy que insira SSL entre o Discourse e o endpoint do S3, mas a comunicação entre o proxy e o endpoint do S3 continuará sendo HTTP sem criptografia.
Então você não usa HTTPS… de forma alguma? Essa é a principal razão mencionada acima.
Olá Jeff, estamos usando HTTPS, por meio do Cloudflare.
Se permitirmos buckets com pontos, precisaremos adicionar uma configuração para que você possa desativar a verificação de SSL ao conectar, ou os usuários que o utilizarem precisarão adicionar um proxy que adicione SSL entre o Discourse e o endpoint do S3, mas ainda haverá HTTP puro entre o proxy e o endpoint do S3.
Tenho quase certeza de que isso seria detectado e tratado automaticamente pelo Cloudflare, sem necessidade de adicionar uma configuração adicional (é uma abordagem que já utilizamos antes com outros serviços).
Compreendo totalmente a vontade de alertar os usuários contra o uso de uma convenção que você considera problemática, mas, dado que nomes válidos de buckets S3 podem conter pontos (e a documentação da AWS recomenda seu uso em diversos cenários), seria algo que você poderia considerar habilitar no futuro?
Que alternativa? Basta criar um novo bucket S3 sem pontos. Não consigo pensar em nenhum motivo para usar um bucket existente para os uploads do Discourse. Isso até facilita a contabilidade, pois não haverá objetos aleatórios não relacionados ao Discourse lá dentro.
