Problem
On S3-compatible backends that don’t support per-object ACLs secure_uploads cannot coexist with publicly-served content.
Avatars and theme/site assets seems to be served via direct, unauthenticated S3 URLs, which requires public read on the object. But the same bucket holds secure post uploads that should stay private in my desired setup — and both (public and private files) share the same path prefixes (original/..., optimized/...). Without per-object ACLs, there’s no way to make the public files public and the other files private.
My current situation: avatars and assets are broken (bucket is private → 403 for those files), while secure post uploads work fine via the /secure-uploads/ proxy.
The core conflict
Secure uploads require an authenticated read path; avatars/assets require an unauthenticated. Both sit behind the same bucket-level boundary, which can’t distinguish them without per-object ACLs.
Requested solutions
- Serve avatars/assets via presigned URLs when the bucket is private and ACLs are disabled — same mechanism as secure uploads. From my perspective this could also work just for logged-in users for scenarios with a non-public Discourse instance.
- Support separate buckets or prefixes for public assets vs. secure uploads, so the access boundary aligns with the public/private boundary and suitable ACLs could be created.
Is either approach feasible, or is there already a supported path I’ve missed?