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.
Hola,
Tuve un problema similar con una causa diferente. Las cargas al bucket de respaldo funcionaban, pero el bucket de cargas no.
Resulta que era porque el bucket de cargas estaba configurado para bloquear todo el acceso público. (Creo que ahora es la configuración predeterminada.) Cuando probé la carga localmente, funcionó bien, pero Discourse estaba cargando con el acceso “public-read”, y S3 lo rechazó. (Habría pensado que S3 guardaría el estado “public-read” en el archivo, pero luego rechazaría los intentos de acceso público.) Al final tuve que agregar registros adicionales para descubrir qué opciones se estaban utilizando para la carga.
Quizás Discourse podría usar la API GetPublicAccessBlock para verificar si el bucket está configurado correctamente al establecer la opción “s3 upload bucket”.
Otra posibilidad es que empecemos a recomendar en la guía de configuración que los usuarios coloquen un CDN de CloudFront delante de su bucket de cargas, en cuyo caso el bloqueo de lectura pública debería mantenerse.
No estoy seguro de cómo debería ser la relación entre el costo y la complejidad en este caso.