Получение 403 (запрещено) при загрузке на S3 с подписанным URL

Ваш запрос должен точно соответствовать подписи. Одна очевидная проблема заключается в том, что вы фактически не включаете шаблонный ACL в запрос, даже если вы включили его в подпись. Измените на это:

var options = { headers: { 'Content-Type': fileType, 'x-amz-acl': 'public-read' } };

Если вы пытаетесь использовать ACL, убедитесь, что ваша роль Lambda IAM имеет s3:PutObjectAcl для данного сегмента, а также что ваш сегмент допускает s3:PutObjectAcl для отправляющего участника (пользователя / iam / учетной записи, которая загружает).

Это то, что исправило это для меня после двойной проверки всех моих заголовков и всего остального.

На основе этого ответа https://stackoverflow.com/a/53542531/2759427

1) Вам может потребоваться использовать подписи S3V4 в зависимости от того, как данные передаются в AWS (фрагмент или поток). Создайте клиента следующим образом:

var s3 = new AWS.S3({
  signatureVersion: 'v4'
});

2) Не добавляйте новые заголовки и не изменяйте существующие заголовки. Запрос должен быть точно подписан.

3) Убедитесь, что сгенерированный URL соответствует тому, что отправляется в AWS.

4) Сделайте тестовый запрос, удалив эти две строки перед подписанием (и удалите заголовки из PUT). Это поможет сузить круг вашей проблемы:

  ContentType: req.body.fileType,
  ACL: 'public-read'

Была такая же проблема, вот как ее решить:

1. Извлеките часть имени файла из подписанного URL-адреса. Напечатайте, что вы правильно извлекаете часть имени файла с параметрами строки запроса. Это очень важно.
2. Кодировать в URI Кодирование имени файла с параметрами строки запроса.
3. Верните URL-адрес из вашей лямбды с закодированным именем файла вместе с другим путем или из службы вашего узла.

Теперь отправьте сообщение из axios с этим URL-адресом, он будет работать.

РЕДАКТИРОВАТЬ1: ваша подпись также будет недействительной, если вы передадите неправильный тип содержимого.

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

Надеюсь, это поможет.

Получение ошибки 403 Forbidden для предварительно подписанной загрузки s3 put также может произойти по нескольким причинам, которые не сразу очевидны:

1. Это может произойти, если вы создаете предварительно подписанный URL-адрес размещения с использованием типа содержимого подстановочного знака, такого как image/*, поскольку подстановочные знаки не поддерживаются.

2. Это может произойти, если вы сгенерируете предварительно подписанный URL-адрес размещения с не указанным типом контента, но затем передадите заголовок типа контента при загрузке из браузера. Если вы не укажете тип контента при создании URL-адреса, вы должны опустить тип контента при загрузке. Помните, что если вы используете инструмент загрузки, такой как Uppy, он может автоматически прикрепить заголовок типа контента, даже если вы его не t указать один. В этом случае вам придется вручную установить пустой заголовок типа контента.

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

Например, создание предварительно подписанного URL-адреса из вашего API:

const AWS = require('aws-sdk')
const uuid = require('uuid/v4')

async function getSignedUrl(contentType) {
    const s3 = new AWS.S3({
        accessKeyId: process.env.AWS_KEY,
        secretAccessKey: process.env.AWS_SECRET_KEY
    })
    const signedUrl = await s3.getSignedUrlPromise('putObject', {
        Bucket: 'mybucket',
        Key: `uploads/${uuid()}`,
        ContentType: contentType
    })

    return signedUrl
}

А затем отправив запрос на загрузку из браузера:

import Uppy from '@uppy/core'
import AwsS3 from '@uppy/aws-s3'

this.uppy = Uppy({
    restrictions: {
        allowedFileTypes: ['image/*'],
        maxFileSize: 5242880, // 5 Megabytes
        maxNumberOfFiles: 5
    }
}).use(AwsS3, {
    getUploadParameters(file) {
        async function _getUploadParameters() {
            let signedUrl = await getSignedUrl(file.type)
            return {
                method: 'PUT',
                url: signedUrl
            }
        }

        return _getUploadParameters()
    }
})

Для получения дополнительной информации также см. Эти два сообщения о переполнении стека: how-to-generate-aws-s3-pre-signed-url-request-без-зная-типа содержимого и S3.getSignedUrl для приема нескольких типов содержимого

Этот код работал с учетными данными и корзиной, которую я создал несколько лет назад, но вызывал ошибку 403 для недавно созданных учетных данных / корзин:

const s3 = new AWS.S3({
  region: region,
  accessKeyId: process.env.AWS_ACCESS_KEY,
  secretAccessKey: process.env.AWS_SECRET_KEY,
})

Исправление заключалось в том, чтобы просто добавить signatureVersion: 'v4'.

const s3 = new AWS.S3({
  signatureVersion: 'v4',
  region: region,
  accessKeyId: process.env.AWS_ACCESS_KEY,
  secretAccessKey: process.env.AWS_SECRET_KEY,
})

Почему? Я не знаю.

Как указывали другие, решение состоит в том, чтобы добавить signatureVerision.

const s3 = new AWS.S3(
  {
    apiVersion: '2006-03-01',
      signatureVersion: 'v4'
  }
);

Там очень подробное обсуждение того же взгляда https://github.com/aws/aws-sdk-js/issues/468

TL; DR: убедитесь, что ваша корзина существует и доступна с помощью ключа AWS, который генерирует подписанный URL.

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

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

Боковое примечание: эта ссылка помогла https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/

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