Problème
Sur les backends compatibles S3 qui ne prennent pas en charge les ACL par objet, secure_uploads ne peut pas coexister avec du contenu servi publiquement.
Les avatars et les assets de thème/site semblent être servis via des URLs S3 directes et non authentifiées, ce qui nécessite une lecture publique sur l’objet. Mais le même bucket contient des uploads de posts sécurisés qui devraient rester privés dans ma configuration souhaitée — et les deux (fichiers publics et privés) partagent les mêmes préfixes de chemin (original/..., optimized/...). Sans ACL par objet, il n’y a aucun moyen de rendre les fichiers publics accessibles publiquement et les autres fichiers privés.
Ma situation actuelle : les avatars et les assets sont cassés (le bucket est privé → 403 pour ces fichiers), tandis que les uploads de posts sécurisés fonctionnent correctement via le proxy /secure-uploads/.
Le conflit principal
Les uploads sécurisés nécessitent un chemin de lecture authentifié ; les avatars/assets nécessitent un accès non authentifié. Les deux se trouvent derrière la même limite au niveau du bucket, qui ne peut pas les distinguer sans ACL par objet.
Solutions demandées
- Servir les avatars/assets via des URLs presignées lorsque le bucket est privé et que les ACL sont désactivées — même mécanisme que pour les uploads sécurisés. De mon point de vue, cela pourrait aussi fonctionner uniquement pour les utilisateurs connectés dans des scénarios avec une instance Discourse non publique.
- Prendre en charge des buckets ou préfixes séparés pour les assets publics par rapport aux uploads sécurisés, afin que la limite d’accès s’aligne avec la frontière public/privé et que des ACL appropriées puissent être créées.
L’une de ces approches est-elle réalisable, ou ai-je manqué une méthode déjà supportée ?