Ковш Amazon S3 возвращается 403 Запрещено

Недавно я унаследовал приложение Rails, которое использует S3 для хранения активов. Я передал все активы в свою корзину S3 без проблем. Однако, когда я изменяю приложение, чтобы указать на новое ведро, я получаю 403 Запретный статус.

Моя корзина S3 настроена со следующими настройками:

Права доступа

Каждый может перечислить

Политика Bucket

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

Конфигурация 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>

Статический веб-хостинг

Enabled.

Что еще я могу сделать, чтобы общественность могла достичь этих активов?

Ответы

Ответ 1

Проблема в том, что передача была выполнена в соответствии с этой нитью, которая сама по себе не является проблемой. Проблема возникла у предыдущего разработчика, не меняющего разрешения на файлы перед передачей. Это означало, что я не мог управлять ни одним из файлов, даже если они были в моем ковше.

Проблема была решена путем повторной загрузки файлов из предыдущего ведра, удаления старых файлов phantom, повторной загрузки свежих файлов и установки их разрешений, чтобы разрешить публичное чтение файлов.

Ответ 2

Я знаю, что это старый поток, но я столкнулся с одной и той же проблемой. У меня было все, что работало месяцами, и это внезапно прекратило работать, давая мне ошибку 403 Forbidden. Оказывается, системные часы были настоящим виновником. Я думаю, что s3 использует своего рода маркер, основанный на времени, который имеет очень короткий срок службы. И в моем случае я просто побежал:

ntpdate pool.ntp.org

И проблема исчезла. Я выполняю CentOS 6, если он имеет какое-либо значение. Это был результат выборки:

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

Надежды помогают!

Ответ 3

может также быть, что надлежащая политика должна быть установлена согласно амазонским документам.

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

поставить под сомнение эту политику

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

Ответ 4

Для меня ни один из других ответов не сработал. Права доступа к файлам, правила хранения и часы были в порядке. Для меня проблема была нерегулярной, и, хотя она может показаться банальной, у меня уже работали следующие:

  1. Выйдите и войдите снова.
  2. Если вы пытаетесь загрузить один файл, попробуйте выполнить массовую загрузку. И наоборот, если вы пытаетесь загрузить один файл, попробуйте выполнить массовую загрузку.

Ответ 5

У меня была такая же проблема, просто добавление * в конце ресурса корзины политики решило ее

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