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.
Je voulais simplement ajouter mon +1 pour autoriser les points dans les noms de buckets S3 au sein de Discourse. AWS le permet lui-même (et l’indique d’ailleurs explicitement) désormais pour l’accès aux contenus S3 basé sur des CNAME. À ma connaissance, tant que le paramètre s3_cdn_url de Discourse est utilisé, les problèmes antérieurs liés à HTTPS ne posent plus de souci, du moins lorsque des services comme Cloudflare sont employés (comme le note @uppfinnarn, les certificats SSL basés sur SNI résolvent ce problème).
Serait-il possible de réexaminer cette question dans une prochaine version ?
Bonjour Rafael, sauf si je passe à côté de quelque chose, bien que ce paramètre permette à Discourse de récupérer depuis une URL CDN, si nous ne pouvons pas spécifier un nom de bucket S3 contenant des points, nous ne pouvons pas réellement y télécharger de fichiers ? Cela impose des contournements peu élégants, comme la configuration de CNAME alternatifs dans des services tiers supplémentaires et non gratuits comme CloudFront (que nous n’utilisons pas du tout pour le moment et que nous préférons éviter).
(Et je suppose qu’au fond, je ne comprends tout simplement pas pourquoi vous voudriez jamais rejeter systématiquement quelque chose qui est un nom de bucket S3 valide !)
Si nous autorisons des buckets contenant des points, nous devons ajouter un paramètre pour désactiver la vérification SSL lors de la connexion, ou les utilisateurs doivent ajouter un proxy qui ajoute une couche SSL entre Discourse et le point de terminaison S3, mais la communication restera en HTTP non chiffré entre le proxy et le point de terminaison S3.
Donc vous n’utilisez pas HTTPS… du tout ? C’est la raison principale mentionnée ci-dessus.
Bonjour Jeff, nous utilisons HTTPS, via Cloudflare.
Si nous autorisons les buckets contenant des points, nous devons ajouter un paramètre pour désactiver la vérification SSL lors de la connexion, ou les utilisateurs doivent ajouter un proxy qui ajoute SSL entre Discourse et le point de terminaison S3, mais cela restera en HTTP simple entre le proxy et le point de terminaison S3.
Je suis presque certain que Cloudflare détectera et gérera cela automatiquement, sans qu’il soit nécessaire d’ajouter un paramètre supplémentaire (c’est une approche que nous avons déjà utilisée avec d’autres services).
Je comprends tout à fait votre volonté d’avertir les utilisateurs contre l’utilisation d’une convention que vous jugez problématique, mais étant donné que les noms de buckets S3 valides peuvent contenir des points (et que la documentation AWS recommande de les utiliser dans divers scénarios), seriez-vous ouvert à envisager de le rendre possible à l’avenir ?
Quelle alternative ? Créez simplement un nouveau bucket S3 sans points. Je ne vois aucune raison d’utiliser un bucket existant pour vos uploads Discourse. Cela simplifie même la comptabilité, car il n’y a pas d’objets aléatoires non liés à Discourse dedans.
Le CDN CloudFront est optionnel. Vous pouvez utiliser n’importe quel autre CDN avec un nom de bucket sans point, et vous n’aurez pas non plus de problèmes liés au HTTPS.
En outre, cette image est la seule chose qui me vient à l’esprit en lisant cet échange.
(Attention : toute personne détenant une habilitation de sécurité américaine actuelle ne doit pas révéler l'image ici.)
