A long-standing issue in Discourse is the S3 CDN URL being ignored when uploading into posts. This results in a generic bucket URL being used instead of the custom CDN URL set in s3 cdn url. This problem is particularly significant for users with private ACLs on their S3 buckets, as it causes broken images in the post preview window.
@DanielMarquard first reported the issue, and @timkelty expressed disappointment that it had gone unfixed for so long. @Stephen suggested that the implementation was not fully supported, but @timkelty argued that the behavior was broken and forced users to adopt an S3 configuration that AWS recommends against.
@sam proposed a potential fix, which was implemented by @vinothkannans. However, the issue regressed, as reported by @RGJ. @vinothkannans provided another fix, but it did not cover custom emojis in the preview, as noted by @Falco. Additionally, the fix did not apply to attachments, as pointed out by @applebee1558. A pull request to fix the attachment issue was submitted by @nbianca.
All of our traffic goes through CloudFront, and static content is fetched by CloudFront from one of several S3 buckets.
With uploads being sent to S3, Discourse embeds the content with a generic bucket URL despite our having s3 cdn url set. Once submitted, posts appear to use the correct URL set in s3 cdn url, although this may also be because we have DISCOURSE_CDN_URL set as well (both are set to the same URL).
The post preview window references the standard S3 URL seen in the unbaked post, though. This is a problem because we use a private ACL on files uploaded to our Discourse uploads bucket, as content on this bucket should never be accessed outside of CloudFront. The result is a broken image in the preview window.
@Stephen, certamente está sujeito a interpretação…
Para mim, parece “quebrado” que ele use a URL do CDN em uma instância e não na outra, além de forçar uma configuração do S3 que a AWS realmente recomenda evitar (ACL pública para um bucket S3).
Sou novo no projeto Discourse em geral, mas certamente posso trabalhar em um PR.
De acordo com a alteração recente, agora estamos obtendo a URL do arquivo enviado diretamente da solicitação de upload inicial. Anteriormente, recebíamos essa informação do endpoint /uploads/lookup-urls.json. Este commit deve corrigir o problema.
.