AWS S3 - How to fix 'The request signature we calculated does not match the signature' error?

后端 未结 30 2585
谎友^
谎友^ 2020-11-29 08:05

I have searched on the web for over two days now, and probably have looked through most of the online documented scenarios and workarounds, but nothing worked for me so far.

相关标签:
30条回答
  • 2020-11-29 08:40

    Most of the time it happens because of the wrong key (AWS_SECRET_ACCESS_KEY). Please cross verify your AWS_SECRET_ACCESS_KEY. Hope it will work...

    0 讨论(0)
  • 2020-11-29 08:41

    After debugging and spending a lot of time, in my case, the issue was with the access_key_id and secret_access_key, just double check your credentials or generate new one if possible and make sure you are passing the credentials in params.

    0 讨论(0)
  • 2020-11-29 08:42

    I had the same problem when tried to copy an object with some UTF8 characters. Below is a JS example:

    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);
    

    Solved by encoding the CopySource with encodeURIComponent()

    0 讨论(0)
  • 2020-11-29 08:42

    I got this error while trying to copy an object. I fixed it by encoding the copySource. This is actually described in the method documentation:

    Params: copySource – The name of the source bucket and key name of the source object, separated by a slash (/). Must be URL-encoded.

    CopyObjectRequest objectRequest = CopyObjectRequest.builder()
                    .copySource(URLEncoder.encode(bucket + "/" + oldFileKey, "UTF-8"))
                    .destinationBucket(bucket)
                    .destinationKey(newFileKey)
                    .build();
    
    0 讨论(0)
  • 2020-11-29 08:43

    In a previous version of the aws-php-sdk, prior to the deprecation of the S3Client::factory() method, you were allowed to place part of the file path, or Key as it is called in the S3Client->putObject() parameters, on the bucket parameter. I had a file manager in production use, using the v2 SDK. Since the factory method still worked, I did not revisit this module after updating to ~3.70.0. Today I spent the better part of two hours debugging why I had started receiving this error, and it ended up being due to the parameters I was passing (which used to work):

    $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'
    ]);
    

    I had to move the catsinhats portion of my bucket/key path to the Key parameter, like so:

    $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'
    ]);
    

    What I believe is happening is that the Bucket name is now being URL Encoded. After further inspection of the exact message I was receiving from the SDK, I found this:

    Error executing PutObject on https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png

    AWS HTTP error: Client error: PUT https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png resulted in a 403 Forbidden

    This shows that the / I provided to my Bucket parameter has been through urlencode() and is now %2F.

    The way the Signature works is fairly complicated, but the issue boils down to the bucket and key are used to generate the encrypted signature. If they do not match exactly on both the calling client, and within AWS, then the request will be denied with a 403. The error message does actually point out the issue:

    The request signature we calculated does not match the signature you provided. Check your key and signing method.

    So, my Key was wrong because my Bucket was wrong.

    0 讨论(0)
  • 2020-11-29 08:43

    In my case, I was using S3 (uppercase) as service name when making request using postman in AWS signature Authorization method

    0 讨论(0)
提交回复
热议问题