When you are using a CDN URL pointing to S3 and create a data export, the link to the export is generated with the S3 URL and hence the download fails.
Please use the CDN URL there as well.
AI-generated summary
The discussion revolves around a bug where data export links generated in Discourse use the S3 URL instead of the CDN URL, causing download failures when direct S3 access is blocked. nodomain highlights the issue, noting that the CDN URL should be used for exports. pfaffman questions the need for CDN caching since downloads are private and occur only once. RGJ references related meta threads, citing a technical limitation: downloads require presigned S3 URLs for proper content-disposition headers, and CDN URLs are not used for downloads—only for inline display. Martin Brennan explains that private attachments must use presigned URLs, making CDN use impractical. nodomain adds that even a signed URL would be acceptable, as the current S3 HTTPS link is problematic. Bathinda seeks clarification on whether this was resolved.
1 Like
That sounds like the desired behaviour. The file will be downloaded only once and is private so there is no reason that it should be cached by the CDN. Right?
2 Likes
But it breaks if you block direct access to the S3 bucket like we have to do due to company guidelines.
2 Likes
Also mentioned in
- Image lightbox "download" link pointing to S3 bucket not CDN
- Downloads coming from S3 even with DISCOURSE_S3_CDN_URL set
- S3 CDN URL not being used on non-image uploads - #4 by martin
and that last topic explains why this is:
It would be good if there was an option to proxy those downloads through Discourse though, if only to not expose the S3 bucket to the world.
3 Likes
In my case I would also be ok with using the signed URL but currently it points directly to the S3 HTTPS URL.
1 Like
Valid point.
@nodomain, was this ever resolved?