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.
Solo quería añadir mi +1 para permitir puntos en los nombres de los buckets de S3 dentro de Discourse. AWS mismo lo permite (de hecho, lo indica) ahora para el acceso basado en CNAME a contenido de S3, y siempre que se utilice la configuración s3_cdn_url en Discourse, hasta donde puedo ver, los problemas anteriores relacionados con HTTPS ya no son problemáticos, al menos cuando se utilizan servicios como Cloudflare (como señala @uppfinnarn, los certificados SSL basados en SNI resuelven este problema).
¿Sería posible reconsiderar esto en una próxima versión?
Hola Rafael, a menos que esté pasando algo por alto, aunque ese parámetro permite a Discourse extraer de una URL de CDN, si no podemos especificar un nombre de bucket de S3 que contenga puntos, ¿realmente no podemos subir a esos buckets? Esto obliga a soluciones poco elegantes, como configurar CNAMEs alternativos en servicios adicionales de terceros no gratuitos como CloudFront (que en este momento no estamos utilizando en absoluto y preferiríamos no tener que usar).
Si permitimos buckets con puntos, debemos agregar una configuración para deshabilitar la verificación de SSL al conectar, o los usuarios que lo utilicen deberán agregar un proxy que añada SSL entre Discourse y el punto final de S3, pero seguirá siendo HTTP sin cifrar entre el proxy y el punto final de S3.
¿Entonces no usas HTTPS… en absoluto? Esa es la razón principal según lo mencionado anteriormente.
Hola Jeff, estamos usando HTTPS, a través de Cloudflare.
{quote}Si permitimos buckets con puntos, debemos agregar una configuración para que puedas deshabilitar la verificación de SSL al conectarte, o los usuarios que lo usen deberán agregar un proxy que añada SSL entre Discourse y el endpoint de S3, pero seguirá siendo HTTP sin cifrar entre el proxy y el endpoint de S3.{/quote}
Estoy bastante seguro de que Cloudflare detectaría y manejaría esto automáticamente, sin necesidad de agregar una configuración adicional (es un enfoque que hemos utilizado antes con otros servicios).
Entiendo perfectamente que quieras advertir a los usuarios sobre el uso de una convención que consideras problemática, pero dado que los nombres válidos de buckets de S3 pueden contener puntos (y la documentación de AWS recomienda usarlos en varios escenarios), ¿sería algo que podrías considerar habilitar en el futuro?
¿Qué alternativa? Simplemente crea un nuevo bucket de S3 sin puntos. No se me ocurre ninguna razón para usar un bucket existente para las cargas de Discourse. Incluso facilita la contabilidad, ya que no hay objetos aleatorios que no sean de Discourse allí.
