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.
Ciao,
ho riscontrato un problema simile con una causa diversa. Gli upload nel bucket di backup funzionavano, ma quelli nel bucket di upload no.
Si è scoperto che il bucket di upload era configurato per bloccare tutti gli accessi pubblici. (Credo che ora sia l’impostazione predefinita.) Quando ho testato l’upload in locale, funzionava correttamente, ma Discourse stava caricando con l’accesso “public-read”, e S3 ha respinto la richiesta. (Avrei pensato che S3 avrebbe salvato lo stato “public-read” sul file, per poi rifiutare i tentativi di accesso pubblico.) Alla fine ho dovuto aggiungere del logging extra per scoprire quali opzioni venivano utilizzate per l’upload.
Forse Discourse potrebbe utilizzare l’API GetPublicAccessBlock per verificare se il bucket è configurato correttamente quando si imposta l’opzione “s3 upload bucket”?
Un’altra possibilità è che iniziamo a raccomandare di posizionare un CDN CloudFront davanti al bucket di upload nella guida alla configurazione; in tal caso, il blocco public-read dovrebbe rimanere attivo.
Non sono sicuro di come dovrebbe apparire il compromesso tra costi e complessità in questo caso.