s3 SignedUrl x-amz-security-token

Question

const AWS = require('aws-sdk');

export function main (event, context, callback) {
  const s3 = new AWS.S3();
  const data = JSON.parse(event.body);`

  const s3Params = {
    Bucket: process.env.mediaFilesBucket,
    Key: data.name,
    ContentType: data.type,
    ACL: 'public-read',
  };

  const uploadURL = s3.getSignedUrl('putObject', s3Params);

  callback(null, {
    statusCode: 200,
    headers: {
      'Access-Control-Allow-Origin': '*'
    },
    body: JSON.stringify({ uploadURL: uploadURL }),
  })
}

Когда я тестирую его локально, он работает нормально, но после развертывания это x-amz-security-token, а затем я получаю ответ об отказе в доступе.Как мне избавиться от этого x-amz-security-token?

Answer 1

У меня была такая же проблема.Все работало без сбоев, используя serverless-offline, но когда я развернулся на Lambda, я начал получать AccessDenied проблемы с URL.При сравнении URL-адресов, возвращаемых между развертываниями serverless-offline и AWS, я заметил, что единственным отличием было включение X-Amz-Security-Token в URL-адрес в качестве параметра строки запроса.После некоторого копания я обнаружил, что назначаемый токен был основан на предполагаемой роли лямбда-функции.Все, что мне нужно было сделать, это присвоить роли соответствующие политики S3, и это сработало.

Answer 2

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

Я первоначально использовал метод, который вы использовали выше, но затем использовалМодуль npm aws-signature-v4 , чтобы увидеть, не было ли оно другого и получала ли вы ту же ошибку.

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

Скрытый в документах (и извините, я не могу найти место, где это указано), указано, что некоторые службы требуют обработки session_token с другими каноническими параметрами запроса.Модуль, которым я пользуюсь, в конце концов его закрепил, как, по-видимому, подразумевают инструкции sig v4, поэтому я изменил его так, чтобы токен был каноническим, и он работал.

Мы обновили живую версию модуля aws-signature-v4, чтобы отразить это изменение, и теперь он отлично работает для подписания ваших запросов s3.

Подписание обсуждается здесь .

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

пример использования (это обернутопри многоэлементной загрузке, таким образом, номер детали и идентификатор загрузки):

function createBaseUrl( bucketName, uploadId, partNumber, objectKey ) {
  let url = sig4.createPresignedS3URL( objectKey, {
    method: "PUT",
    bucket: bucketName,
    expires: 21600,
    query: `partNumber=${partNumber}&uploadId=${uploadId}`
  });
  return url;
}