amazon-web-services - services - costos actuales de servicios de la nube

El cubo Amazon S3 regresa 403 Prohibido

Question

Recientemente heredé una aplicación de Rails que usa S3 para el almacenamiento de activos. He transferido todos los activos a mi cubo S3 sin problemas. Sin embargo, cuando modifico la aplicación para apuntar al nuevo cubo obtengo 403 Forbidden Status.

Mi cubo S3 está configurado con la siguiente configuración:

Permisos

Todos pueden listar

Política de Cubo

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucketname/*"
}
]
}

Configuración de CORS

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
</CORSRule>
<CORSRule>
<AllowedOrigin>https://www.appdomain.com</AllowedOrigin>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Alojamiento web estático

Habilitado

¿Qué más puedo hacer para permitir que el público llegue a estos activos?

Answer 1

El problema es que la transferencia se hizo de acuerdo con este hilo , que por sí solo no es un problema. El problema vino del desarrollador anterior que no cambió los permisos en los archivos antes de transferir. Esto significaba que no podía gestionar ninguno de los archivos, a pesar de que estaban en mi cubo.

El problema se resolvió volviendo a descargar los archivos limpiamente del depósito anterior, eliminando los viejos archivos fantasma, volviendo a cargar los archivos nuevos y estableciendo sus permisos para permitir la lectura pública de los archivos.

Answer 2

Sé que este es un hilo viejo, pero acabo de encontrar el mismo problema. Todo funcionó durante meses y de repente dejó de funcionar y me dio un error 403 Forbidden . Resulta que el reloj del sistema fue el verdadero culpable. Creo que s3 usa algún tipo de token basado en el tiempo que tiene una vida útil muy corta. Y en mi caso acabo de correr:

ntpdate pool.ntp.org

Y el problema desapareció Estoy ejecutando CentOS 6 si tiene alguna relevancia. Este fue el resultado de la muestra:

19 Aug 20:57:15 ntpdate[63275]: step time server ip_address offset 438.080758 sec

¡Esperanza en ayuda!

Answer 3

también podría ser que se deba establecer una política adecuada de acuerdo con los documentos de Amazon.

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html

dar al cubo en cuestión esta política

{
"Version":"2012-10-17",
"Statement":[{
"Sid":"PublicReadGetObject",
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::YOUR-BUCKET-NAME/*"
]
}
]
}