AWS Cloudfront возвращает 403 из API-запроса в корзину S3 - PullRequest
Новая
       19

AWS Cloudfront возвращает 403 из API-запроса в корзину S3

1 голос
/ 23 апреля 2020

Я работаю над приложением для усиления реакции. Из приложения я опрашиваю S3 bucket, который, как я ожидаю, будет заполнен через пару минут. Для ясности поток будет:

  1. Пользователь загружает текстовый файл на S3, и приложение получает URL-адрес файла в ответе
  2. Затем приложение отправляет запрос на aws api-gateway с S3 bucket uri, который запускает lambda, который затем вызывает aws textract, что, в свою очередь, запускает секунду lambda, которая записывает в S3 bucket. Первый lambda возвращает в приложение jobId.
  3. Затем приложение запрашивает S3 bucket, чтобы получить файл ответов с помощью jobId и отобразить этот файл пользователю.

Первоначально при опросе сегмента я использовал URL-адрес корзины результатов в своем вызове API. Это прекрасно работает при локальном запуске приложения, так как URL-адрес корзины использует протокол http, возвращая status code 404 до тех пор, пока файл не будет создан.

Затем я создал дистрибутив cloudfront для приложения и запрос опроса возвращает ошибку: xhr.js:178 Mixed Content: The page at '<>my cloudfront url>' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint '<my endpoint>'. This request has been blocked; the content must be served over HTTPS., что имеет смысл.

Однако изменение поведения протокола средства просмотра в распределении облачного фронта приложения с Redirect HTTP to HTTPS на HTTP and HTTPS, похоже, не сработало.

Поэтому я подумал, что мог бы создать второй дистрибутив облачного фронта для корзины результатов S3, так как он использует https. Тем не менее, когда я сейчас запускаю вызов API, я получаю 403 status code и больше не 404. Поэтому я попытался настроить пользовательский ответ об ошибке, сопоставив ошибку 403 с 404. Я долго ждал, так как облачный фронт может занять некоторое время, но, похоже, это ничего не меняет. Изменяя код в моем приложении, можно ожидать, что 403 вместо 404 сработает, и через некоторое время, как только файл будет записан с результатами S3 bucket, я получаю файл и отображаю его в приложении. Но я не хочу ожидать 403, поскольку это совершенно неправильный код для чего-то, что не существует.

У меня есть несколько вопросов здесь:

  1. Is это правильный подход (с распределением cloudfront для результатов S3 bucket)?
  2. Почему я получу 403 при использовании URL-адреса cloudfront вместо 404, который я получал, когда используя S3 url результатов?
  3. Если точка 1 является правильным подходом, что мне делать, чтобы исправить точку 2?

1 Ответ

0 голосов
/ 23 апреля 2020

Таким образом, решение, по-видимому, заключается не в определении особых сообщений об ошибках, а в самом деле изменении политики доступа к корзине S3, как описано здесь .

Изначально моя политика корзины была: 

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

Затем я обновил его до: 

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

Это, похоже, решило мою проблему. Однако это не объясняет, почему я получаю 404 перед использованием cloudfront, а затем 403 при использовании cloudfront.

...