it-swarm.com.ru

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

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

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

Разрешения

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

Bucket Policy

{
 "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.

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

41
thatgibbyguy

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

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

24
thatgibbyguy

Я знаю, что это старая тема, но я столкнулся с той же проблемой. У меня все работало месяцами, и оно внезапно перестало работать, выдавая ошибку 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

Надеюсь на помощь!

22
Sthe

возможно также, что в соответствии с документацией Amazon необходимо установить правильную политику.

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/*"
      ]
    }
  ]
}
10
Da Rod

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

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

Одна странная вещь, которая исправила это после того, как я уже настроил правильные права доступа, заключалась в том, что я удалил расширение из имени файла. Таким образом, у меня было много элементов в корзине с одинаковыми правами доступа, и некоторые работали с поиском, а некоторые возвращали 403. Единственное отличие заключалось в том, что у неработающих элементов был .png в конце имени файла. Когда я убрал то они работали нормально. Понятия не имею почему.

0
andrewcockerham