Problem
Bei S3-kompatiblen Backends, die keine pro-Objekt-ACLs unterstützen, kann secure_uploads nicht mit öffentlich bereitgestellten Inhalten koexistieren.
Avatare und Theme-/Site-Assets werden anscheinend über direkte, nicht authentifizierte S3-URLs bereitgestellt, was einen öffentlichen Lesezugriff auf das Objekt erfordert. Aber derselbe Bucket enthält sichere Post-Uploads, die in meinem gewünschten Setup privat bleiben sollten – und beide (öffentliche und private Dateien) teilen dieselben Pfad-Präfixe (original/..., optimized/...). Ohne pro-Objekt-ACLs gibt es keine Möglichkeit, die öffentlichen Dateien öffentlich und die anderen Dateien privat zu machen.
Meine aktuelle Situation: Avatare und Assets sind defekt (Bucket ist privat → 403 für diese Dateien), während sichere Post-Uploads über den /secure-uploads/-Proxy einwandfrei funktionieren.
Der Kernkonflikt
Sichere Uploads erfordern einen authentifizierten Lesezugriff; Avatare/Assets erfordern einen nicht authentifizierten. Beide liegen hinter derselben Bucket-Ebene, die sie ohne pro-Objekt-ACLs nicht unterscheiden kann.
Angeforderte Lösungen
- Bereite Avatare/Assets über presigned URLs bereit, wenn der Bucket privat ist und ACLs deaktiviert sind – derselbe Mechanismus wie bei sicheren Uploads. Aus meiner Perspektive könnte dies auch nur für angemeldete Benutzer funktionieren, was für Szenarien mit einer nicht-öffentlichen Discourse-Instanz geeignet wäre.
- Unterstütze separate Buckets oder Präfixe für öffentliche Assets im Vergleich zu sicheren Uploads, sodass die Zugriffsgrenze mit der öffentlich/privat-Grenze übereinstimmt und geeignete ACLs erstellt werden können.
Ist einer dieser Ansätze machbar, oder habe ich einen bereits unterstützten Weg übersehen?