Aws-sdk-js: S3 pre-signed URL broken after upgrade to 2.151.0

[peterpeterparker]

Hi,

After the upgrade from aws-sdk 2.148.0 to 2.151.0 I'm not able to upload anything to my S3 anymore.

After digging a bit, it looks like that something is broken with the pre-signed URLs in this new version of the library. I double checked the release notes and didn't see anything about any modifications which would have to be performed in my code regarding this topic.

Without changing any pieces of codes of all servers and apps except upgrading to 2.151.0, I now face a 403 - Forbidden access due to a SignatureDoesNotMatch

<Error><Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>

Rollbacking to 2.148.0 solve the issue.

Best regards

If needed, my server code to generate the pre-signed url which didn't changed since more than a year:

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

AWS.config.update({accessKeyId: "myKeyId", secretAccessKey: "mySecret"});
AWS.config.region = 'eu-west-1';

var s3 = new AWS.S3({useDualstack: true});

var imgName = req.body.imgName;
var contentType = req.body.contentType;

// Expires in seconds
var params = {
    Bucket: 'mybucket',
    Key: imgName, Expires: 600,
    ContentType: contentType,
    ContentEncoding: 'base64',
    ACL: 'public-read'};
    s3.getSignedUrl('putObject', params, function (err, url) {
        if (err) {
           res.status(500).json({
                error: "Signed S3 url for putObject can't be created. " + JSON.stringify(err)
           });
       } else {
          res.json({url: url});
      }
  });

[chrisradek]

@peterpeterparker
Can you share the general pattern for your bucket name? Specifically if it contains any dots, like xxx.xx.xxx?

[peterpeterparker]

@chrisradek sure, here you go

xxxx-xx-xx.s3.dualstack.eu-west-1.amazonaws.com

[chrisradek]

@peterpeterparker
Thanks! I am able to reproduce the issue.

Interestingly, I don't get a signature mismatch error when I exclude ContentEncoding from the parameters. More for my own curiosity, why do you set the encoding to base64? We've seen this in other examples, and base64 isn't actually a registered content coding, and S3 doesn't perform any transformations based on the value.

[peterpeterparker]

@chrisradek thank you for the confirmation, good to hear you could reproduce it!

I checked my git history to try to remember why I set this encoding to base64 and I found a commit in June 2016 with the comment Me: Encoding for S3 ... so well to be honest, except that I feel ashamed for such a bad comment, I can't tell you why I set this encoding.

Like you said, there are examples containing this option online, I think I just based myself on them and since I manage the images as bas64 and upload them in this format, I probably thought this was the right way to go and since it was working like a charm...

Do you want me to try 2.151.0and remove the ContentEncoding option to see if it works too?

[chrisradek]

@peterpeterparker
No worries, I was just curious if it was from following a tutorial, or if it was needed to make something else work. No judgement here!

If you're able, it'd be great to get confirmation from you that removing ContentEncoding works in 2.151.0. Even if that does fix it for you, we'll still want to fix it in the SDK.

[peterpeterparker]

@chrisradek yes you are totally right, removing ContentEncoding while using 2.151.0 totally solve the issue. thx a lot!

[chrisradek]

@peterpeterparker
Sweet! I also found what's causing the new behavior you're seeing. The endpoint resolution for S3 was recently changed (a changelog entry was missed), and it looks like that had the side-effect of changing the default signature version for all presigned urls to V4. Prior to this change, presigned urls in regions that supported signatureVersion v2/s3 would default to that instead.

We'll definitely need to fix this, as sigv2 URLs act a little differently than sigv4 URLs (notably, sigv2 have a much longer max expiration time). You could get around this with the latest version of the SDK by instantiating your S3 client with signatureVersion: 'v2', or hold off until we release a fix (should be relatively soon).

[peterpeterparker]

Thx for the clear explanation. I stay at your disposal if you need a tester

[chrisradek]

@peterpeterparker
A fix has just been merged into master, and will make it into the next release of the SDK.

Thank you for reporting this!

[peterpeterparker]

Already? Sweet, so fast. Thx a lot for the quick fix and support @chrisradek

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.