No they aren’t and they got structure internally. Just wanted to ensure that it’s okay to see only 2 folders and nothing else there.
Now that’s VERY useful information. Maybe not include Option 2 at all since it could break many things. Infact in option 1 I’d probably highlight that one shouldn’t change the bucket for the uploads since it would require a rebake etc, only change the bucket for backups.
This is exactly what was looking for, don’t touch the upload, just move Backups to a new bucket or a sub folder.
Bonjour,
J’ai rencontré un problème similaire avec une cause différente. Les uploads vers le bucket de sauvegarde fonctionnaient, mais ceux vers le bucket d’uploads ne fonctionnaient pas.
Il s’avère que le bucket d’uploads était configuré pour bloquer tout accès public. (Ce qui, je pense, est désormais le paramètre par défaut.) Lors de mes tests d’upload en local, tout fonctionnait correctement, mais Discourse tentait d’uploader avec l’accès « public-read », ce que S3 a rejeté. (J’aurais pensé que S3 enregistrerait le statut « public-read » sur le fichier, puis rejetterait les tentatives d’accès public.) J’ai dû ajouter du journalisation supplémentaire pour identifier les options utilisées lors de l’upload.
Peut-être que Discourse pourrait utiliser l’API GetPublicAccessBlock pour vérifier si le bucket est correctement configuré lors de la définition du paramètre « s3 upload bucket » ?
Une autre possibilité serait de commencer à recommander aux utilisateurs d’ajouter un CDN CloudFront devant leur bucket de téléchargement dans le guide de configuration, auquel cas le blocage public-read devrait rester en place.
Je ne suis pas certain de ce à quoi devrait ressembler le compromis entre coût et complexité dans ce cas.