Подтвердить что ты не робот

Как исправить "Подписанная нами подпись запроса не соответствует ошибке подписи?

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

Я на AWS SDK для PHP V2.8.7, работающий на PHP 5.3. Я пытаюсь подключиться к своей корзине S3 со следующим кодом:

// Create a `Aws` object using a configuration file

        $aws = Aws::factory('config.php');

        // Get the client from the service locator by namespace
        $s3Client = $aws->get('s3');

        $bucket = "xxx";
        $keyname = "xxx";

        try {
            $result = $s3Client->putObject(array(
                'Bucket'        =>      $bucket,
                'Key'           =>      $keyname,
                'Body'          =>      'Hello World!'
            ));
            $file_error = false;
        } catch (Exception $e) {
            $file_error = true;
            echo $e->getMessage();
            die();
        }
        //  

Мой файл config.php выглядит следующим образом:

<?php

return array(
    // Bootstrap the configuration file with AWS specific features
    'includes' => array('_aws'),
    'services' => array(
        // All AWS clients extend from 'default_settings'. Here we are
        // overriding 'default_settings' with our default credentials and
        // providing a default region setting.
        'default_settings' => array(
            'params' => array(
                'credentials' => array(
                    'key'    => 'key',
                    'secret' => 'secret'
                )
            )
        )
    )
);

Он выдает следующую ошибку:

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

Я уже проверил ключ доступа и секрет как минимум 20 раз, сгенерировал новые, использовал разные методы для передачи информации (т.е. профиля и включая учетные данные в коде), но в настоящий момент ничего не работает.

4b9b3361

Ответ 1

После двух дней отладки я наконец обнаружил проблему...

Ключ, который я назначил объекту, начинался с точки, т.е. ..\images\ABC.jpg, и это приводило к возникновению ошибки.

Я хотел бы, чтобы API предоставил более значимое и актуальное сообщение об ошибке, увы, надеюсь, это поможет кому-то еще!

Ответ 2

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

Ответ 3

У меня была такая же проблема при попытке скопировать объект с некоторыми символами UTF8. Ниже приведен пример JS:

var s3 = new AWS.S3();

s3.copyObject({
    Bucket: 'somebucket',
    CopySource: 'path/to/Weird_file_name_ðÓpíu.jpg',
    Key: 'destination/key.jpg',
    ACL: 'authenticated-read'
}, cb);

Решено путем кодирования CopySource с помощью encodeURIComponent()

Ответ 4

На самом деле в Java я получал такую ​​же ошибку. После траты 4 часа на отладку я обнаружил, что проблема была в метаданных в объектах S3, поскольку в файлах s3 было место, в то время как они занимали элементы управления кешем. Это пространство было разрешено в 1.6. *, Но в 1.11. * Он запрещен и, таким образом, выбрасывает ошибку несоответствия подписи

Ответ 5

Если ни одно из упомянутых решений не работает, попробуйте использовать

aws configure

эта команда откроет набор параметров, запрашивающих ключи, регион и формат вывода.

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

Ответ 6

Я только что испытал эту загрузку изображения на S3, используя AWS SDK с React Native. Оказалось, что это вызвано параметром ContentEncoding.

Удаление этого параметра "исправило" проблему.

Ответ 7

Для меня я использовал axios и по умолчанию он отправляет заголовок

content-type: application/x-www-form-urlencoded

поэтому я изменяю, чтобы отправить:

content-type: application/octet-stream

а также пришлось добавить этот тип контента в подпись AWS

const params = {
    Bucket: bucket,
    Key: key,
    Expires: expires,
    ContentType = 'application/octet-stream'
}

const s3 = new AWS.S3()
s3.getSignedUrl('putObject', params)

Ответ 8

В предыдущей версии aws-php-sdk до устаревания метода S3Client::factory() вам было разрешено разместить часть пути к файлу или Key как он вызывается в S3Client->putObject(), в параметре корзины. У меня был файловый менеджер в производственном использовании, использующий v2 SDK. Поскольку фабричный метод все еще работал, я не пересматривал этот модуль после обновления до ~3.70.0. Сегодня я потратил лучшую часть двухчасовой отладки, почему я начал получать эту ошибку, и это в конечном итоге было связано с параметрами, которые я передавал (которые раньше работали):

$s3Client = new S3Client([
    'profile' => 'default',
    'region' => 'us-east-1',
    'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
    'Bucket' => 'awesomecatpictures/catsinhats',
    'Key' => 'whitecats/white_cat_in_hat1.png',
    'SourceFile' => '/tmp/asdf1234'
]);

Я должен был переместить часть с помощью catsinhats моего пути bucket/key к параметру Key следующим образом:

$s3Client = new S3Client([
    'profile' => 'default',
    'region' => 'us-east-1',
    'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
    'Bucket' => 'awesomecatpictures',
    'Key' => 'catsinhats/whitecats/white_cat_in_hat1.png',
    'SourceFile' => '/tmp/asdf1234'
]);

Я верю, что происходит то, что имя Bucket теперь кодируется URL. После дальнейшей проверки точного сообщения, которое я получил от SDK, я обнаружил это:

Ошибка выполнения PutObject на https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png

Ошибка HTTP AWS: ошибка клиента: PUT https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png привел к 403 Forbidden

Это показывает, что / I, предоставленный моему параметру Bucket, был выполнен через urlencode() и теперь равен %2F.

Принцип работы подписи довольно сложен, но проблема сводится к тому, что ключ и ключ используются для создания зашифрованной подписи. Если они не совпадают точно как на вызывающем клиенте, так и в AWS, то в запросе будет отказано 403. Сообщение об ошибке фактически указывает на проблему:

Рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ и метод подписи.

Итак, мой Key был неправильным, потому что мое Bucket было неправильно.

Ответ 9

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

Ответ 10

В моем случае я проанализировал URL S3 на его компоненты.

Например:

Url:    s3://bucket-name/path/to/file

Был разобран в:

Bucket: bucket-name
Path:   /path/to/file

Часть пути, содержащая начальный символ '/', не выполнила запрос.

Ответ 11

В моем случае имя корзины было неверным, оно включало первую часть ключа (bucketxxx/keyxxx) - в подписи не было ничего плохого.

Ответ 12

В моем случае (python) это не удалось, потому что в файле были две строки кода, унаследованные от старого кода

http.client.HTTPConnection._http_vsn = 10 http.client.HTTPConnection._http_vsn_str = 'HTTP/1.0'

Ответ 13

Я мог бы решить эту проблему с помощью установки переменных среды.

export AWS_ACCESS_KEY=
export AWS_SECRET_ACCESS_KEY=

В IntelliJ + py.test я устанавливаю переменные среды с помощью [Run] > [Edit Configurations] > [Configuration] > [Environment] > [Environment variables]

Ответ 14

Другая возможная проблема может заключаться в том, что мета-значения содержат не символы US-ASCII. Для меня это помогло UrlEncode значения при добавлении их в putRequest:

request.Metadata.Add(AmzMetaPrefix + "artist", HttpUtility.UrlEncode(song.Artist));
request.Metadata.Add(AmzMetaPrefix + "title", HttpUtility.UrlEncode(song.Title));

Ответ 15

Я столкнулся с этим в образе Docker с конечной точкой не-AWS S3, когда использовал последнюю версию awscli доступную для растяжения Debian, то есть версию 1.11.13.

Обновление до версии CLI 1.16.84 решило проблему.

Чтобы установить последнюю версию CLI с Dockerfile, основанным на растянутом образе Debian, вместо:

RUN apt-get update
RUN apt-get install -y awscli
RUN aws --version

Использование:

RUN apt-get update
RUN apt-get install -y python-pip
RUN pip install awscli
RUN aws --version

Ответ 16

Я должен был установить

Aws.config.update({
  credentials: Aws::Credentials.new(access_key_id, secret_access_key)
})

ранее с ruby aws sdk v2 (возможно, что-то похожее и в других языках)

Ответ 17

Я не знаю, сталкивался ли кто-либо с этой проблемой при попытке проверить выводимый URL-адрес в браузере, но если вы используете Postman и пытаетесь скопировать сгенерированный URL-адрес AWS из вкладки RAW, из-за экранирования обратной косой черты вы получите выше ошибка.

Используйте вкладку Pretty чтобы скопировать и вставить URL, чтобы увидеть, работает ли он на самом деле.

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

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

Ответ 18

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

https://....amazonaws.com/myapi//myendpoint URL-адрес был похож на https://....amazonaws.com/myapi//myendpoint. Я удалил лишнюю косую черту в конф, и это сработало.

Не самое явное сообщение об ошибке в моей жизни.

Ответ 19

В моем случае я вызывал s3request.promise().then() incorreclty, что вызвало два выполнения запроса, когда был сделан только один вызов.

Я имею в виду, что я перебирал 6 объектов, но было сделано 12 запросов (вы можете проверить это, войдя в консоль или отладив сеть в браузере).

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

Ответ 20

Я была такая же проблема. У меня был метод по умолчанию, PUT установлен для определения предварительно подписанного URL, но я пытался выполнить GET. Ошибка произошла из-за несоответствия метода.

Ответ 21

У меня была такая же ошибка в nodejs. Но добавление signatureVersion в конструктор s3 мне помогло:

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

Ответ 22

Получил эту ошибку при загрузке документа в CloudSearch через Java SDK. Проблема была из-за специального символа в документе для загрузки. Ошибка "Рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой секретный ключ доступа AWS и метод подписи". очень вводит в заблуждение.

Ответ 23

создание нового ключа доступа работало для меня.

Ответ 24

Я решил эту проблему, изменив публичные разрешения на моем AWS s3 bucket и добавив ниже конфигурацию CORS в мои настройки bucket.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration>
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Дополнительную информацию см. в документации AWS s3.

Ответ 25

Как уже говорили другие, у меня возникла точно такая же проблема, и она оказалась связана с паролем/секретом доступа. Я сгенерировал пароль для моего пользователя s3, который был недействительным, и он не сообщил мне. При попытке связаться с пользователем выдает эту ошибку. Кажется, что не нравятся определенные или все символы в паролях (по крайней мере, для Minio)

Ответ 26

Я получаю ту же ошибку по следующей причине.

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

Благодарю вас

Ответ 27

Вы указали неверные aws_access_key_id и aws_secret_access_key.