Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
Ask Question
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.
I am on
AWS SDK
for PHP V2.8.7 running on PHP 5.3.
I am trying to connect to my Amazon S3 bucket with the following code:
// 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();
My config.php file is as follows:
return [
// Bootstrap the configuration file with AWS specific features
'includes' => ['_aws'],
'services' => [
// 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' => [
'params' => [
'credentials' => [
'key' => 'key',
'secret' => 'secret'
It is producing the following error:
The request signature we calculated does not match the signature you provided. Check your key and signing method.
I've already checked my access key and secret at least 20 times, generated new ones, used different methods to pass in the information (i.e. profile and including credentials in code) but nothing is working at the moment.
–
–
–
–
After two days of debugging, I finally discovered the problem...
The key I was assigning to the object started with a period i.e. ..\images\ABC.jpg, and this caused the error to occur.
I wish the API provides more meaningful and relevant error message, alas, I hope this will help someone else out there!
–
–
–
–
–
–
–
–
I had the same error in nodejs. But adding signatureVersion in s3 constructor helped me:
const s3 = new AWS.S3({
apiVersion: '2006-03-01',
signatureVersion: 'v4',
–
–
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()
–
–
My AccessKey had some special characters in that were not properly escaped.
I didn't check for special characters when I did the copy/paste of the keys. Tripped me up for a few mins.
A simple backslash fixed it. Example (not my real access key obviously):
secretAccessKey: 'Gk/JCK77STMU6VWGrVYa1rmZiq+Mn98OdpJRNV614tM'
becomes
secretAccessKey: 'Gk\/JCK77STMU6VWGrVYa1rmZiq\+Mn98OdpJRNV614tM'
I've just encountered this and, I'm a little embarrassed to say, it was because I was using an HTTP POST request instead of PUT.
Despite my embarrassment, I thought I'd share in case it saves somebody an hour of head scratching.
–
's3',
aws_access_key_id='AKIAIO5FODNN7EXAMPLE',
aws_secret_access_key='ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE',
config=Config(signature_version='s3v4')
Actually in Java i was getting same error.After spending 4 hours to debug it what i found that that the problem was in meta data in S3 Objects as there was space while sitting cache controls in s3 files.This space was allowed in 1.6.* version but in 1.11.* it is disallowed and thus was throwing the signature mismatch error
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.
–
For me I used axios and by deafult it sends header
content-type: application/x-www-form-urlencoded
so i change to send:
content-type: application/octet-stream
and also had to add this Content-Type to AWS signature
const params = {
Bucket: bucket,
Key: key,
Expires: expires,
ContentType: 'application/octet-stream'
const s3 = new AWS.S3()
s3.getSignedUrl('putObject', params)
Another possible issue might be that the meta values contain non US-ASCII characters. For me it helped to UrlEncode the values when adding them to the putRequest:
request.Metadata.Add(AmzMetaPrefix + "artist", HttpUtility.UrlEncode(song.Artist));
request.Metadata.Add(AmzMetaPrefix + "title", HttpUtility.UrlEncode(song.Title));
aws configure
This command (Getting started with the AWS CLI) will open a set of options asking for keys, region and output format.
Hope this helps!
–
I just experienced this uploading an image to S3 using the AWS SDK with React Native. It turned out to be caused by the ContentEncoding parameter.
Removing that parameter "fixed" the issue.
–
–
Like others, I also had the similar issue but in java sdk v1. For me, below 2 fixes helped me.
My key to object looked like this /path/to/obj/. In this, i first removed the / in the beginning.
Further, point 1 alone did not solve the issue. I upgraded my sdk version from 1.9.x to 1.11.x
After applying both the fixes, it worked. So my suggestion is not slog it out. If nothing else is working, just try upgrading the lib.
I don't know if anyone came to this issue while trying to test the outputted URL in browser but if you are using Postman and try to copy the generated url of AWS from the RAW tab, because of escaping backslashes you are going to get the above error.
Use the Pretty tab to copy and paste the url to see if it actually works.
I run into this issue recently and this solution solved my issue. It's for testing purposes to see if you actually retrieve the data through the url.
This answer is a reference to those who try to generate a download, temporary link from AWS or generally generate a URL from AWS to use.
–
I was getting this error in our shared environment where the SDK was being used, but using the same key/secret and the aws cli, it worked fine. The build system script had a space after the key and secret and session keys, which the code read in as well. So the fix for me was to adjust the build script to remove the spaces after the variables being used.
Just adding this for anyone who might miss that frustrating invisible space at the end of their creds.
In my case (python) it failed because I had these two lines of code in the file, inherited from an older code
http.client.HTTPConnection._http_vsn = 10
http.client.HTTPConnection._http_vsn_str = 'HTTP/1.0'
I encountered this in a Docker image, with a non-AWS S3 endpoint, when using the latest awscli version available to Debian stretch, i.e. version 1.11.13.
Upgrading to CLI version 1.16.84 resolved the issue.
To install the latest version of the CLI with a Dockerfile based on a Debian stretch image, instead of:
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
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Amazon S3 Error: The request signature we calculated does not match the signature you provided. Check your key and signing method
See more linked questions
