При тестировании предварительно подписанного URL-адреса AWS S3 возвращается 403 Forbidden (Nodejs)

У меня есть функция Lambda Nodejs за API-шлюзом, которая успешно возвращает предварительно подписанный URL:

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

function getSignedUrl(id, type) {
  const key = `uploads/${id}.${type}`;
  return S3.getSignedUrl('putObject', {
    Bucket: 'example-bucket-name',
    Key: key,
    Expires: 300
  });
}

Предварительно подписанный URL-адрес может выглядеть так:

Однако при тестировании указанного URL-адреса в браузере я получаю SignatureDoesNotMatch. Что, я думаю, кажется справедливым, поскольку позже я хочу использовать это только с PUT из приложения.

Однако, используя curl или postman, я получаю 403 Forbidden:

У функции Lambda есть следующие разрешения:

curl -v -X PUT -T 489eb7115d0c479eaf9c3b6a01eb1893.png "https://example-bucket-name.s3.eu-central-1.amazonaws.com/uploads/489eb7115d0c479eaf9c3b6a01eb1893.png?Content-Type=image%2Fpng&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIARTVN4TPKUACY5POZ%2F20200616%2Feu-central-1%2Fs3%2Faws4_request&X-Amz-Date=20200616T104031Z&X-Amz-Expires=300&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEEMaDGV1LWNlbnRyYWwtMSJHMEUCIQCDd%2B5hFjcBd%2FA6TEV7Se6L%2B6V8VtgCrMg0%2FbOkoGKy1wIgL20u20i%2B80rnBf49MfU1T3MQK2RQdoyQF6SwGQiYgeMq7gEIvP%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARABGgwxMTA5NjAwOTAwNjkiDIcy2z8%2FpQIhMOOaZirCAUFhV6uGF%2Ff44lDl%2BaFxIt9D302gcuPaxlrgZWlRMHb%2FEdrKFJsWP%2FG7%2B6ovilKh9WmcBX1fzuVa%2BHQ6rv6OaCueMEnDOBEj%2FvJ1hrI%2FwMDF1RLVlqq7pTDp6h6hmUxPfbqXu1k8sjcFotVzXZTzR0dX6kmWl41uEvaglXjrGG3ApvviH%2BSFLdUdvK9PBgrgSlamGIhxdJN75xxBzQMELfdpPJ6QanhLEwIa%2FuMliHPliXC2fasMzFEheA3Xmik43McnMJ3DovcFOuABdae1G7uUXOSaQzGZ7IjPLLZnMFfow4SzosQHlMUurlqQATPbieC9W3McsMVwggwzZX6BcN9OJb%2B0Ag3x9pS5eLnLsEio%2FyAPZJfXzoGBH5AdZ6TAZtC5cgKy0TEebH%2F3bF4%2FiamoTQ6YcZ4f48NefoNFHcRPXl3VF%2FdINmuTSG1cNlh2svT9jAUfOgaeK7tnFAW79L38Nv7xnnFMYFpyxoUx8XVkffCXmq15dyG7rLIR0FHkJ7p4C8eEqbQzOj%2Fsj1ELFFAWPtq38ZgFnWF%2BYf6W4UrkHD9AGdUucD1qvAA%3D&X-Amz-Signature=e11f346296a979e586b8f81a9db2ef2ce58c9f7a13a4f3c31f9a0bb9997b8b81&X-Amz-SignedHeaders=host"

Корзина S3 имеет следующие правила CORS:

s3:ListBucket          Allow: arn:aws:s3:::example-bucket-name
s3:GetBucketLocation   Allow: arn:aws:s3:::example-bucket-name
s3:PutObject           Allow: arn:aws:s3:::example-bucket-name/uploads/*

Вот список ACL для сегмента:

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

Может быть, указанное выше правило DenyUnEncryptedTraffic вызывает ошибку 403? Я проверил это, удалив указанное правило, но все равно получаю 403.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSConfigBucketPermissionsCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "config.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::example-bucket-name"
        },
        {
            "Sid": "DenyUnEncryptedTraffic",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": "arn:aws:s3:::example-bucket-name/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Блокировать весь публичный доступ включен!

Владелец ведра имеет полный доступ к ведру!

Я уже потратил на это слишком много времени и действительно нуждаюсь в помощи!

Хорошо, теперь я чувствую себя глупо:


person NJones    schedule 16.06.2020    source источник


Ответы (4)


Только что протестировал указанный URL-адрес Presigned PUT с помощью Postman, и как-то он работает:

введите здесь описание изображения

Убедитесь, что вы ввели предварительно подписанный URL-адрес, выберите PUT, а затем выберите двоичный файл и добавьте файл.

Я оставлю это на тот случай, если кто-то сочтет это полезным.

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

person NJones    schedule 16.06.2020

Причина, по которой AWS возвращает ошибку SignatureDoesNotMatch (403), обычно заключается в том, что секретный ключ является неверным.

person Shahar Yakov    schedule 21.06.2020

Будьте осторожны при создании URL-адреса знака, если код, который генерирует URL-адрес знака, не имеет правильного разрешения на IAM, у вас не будет ошибок при создании предварительно подписанного URL-адреса, но у вас будут ошибки при использовании URL-адреса. .

person raul7    schedule 17.06.2020