Signature mismatch on non url-encoded uris
jaedle opened this issue · comments
Hey 👋
That's a great tool! I am using this tool to perform requests against APIs which are protected by IAM-Authentication. Those apis contain query parameters which parameters may require url-encoding.
It looks like there is a problem with uris which are not url-encoded.
awscurl --service s3 https://awscurl-sample-bucket.s3.amazonaws.com/?query=para:meterResults in an error:
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>.../AWSAccessKeyId><StringToSign>AWS4-HMAC-SHA256
20210608T045117Z
Even though it looks like the underlying implementation correctly escapes the url (like for example curl does) when performing the request, but the signature is calculated for the unescaped uri and this results in a signature mismatch.
Running with escaped uri parameters works perfectly fine.
awscurl --service s3 https://awscurl-sample-bucket.s3.amazonaws.com/?query%3Dpara%3Ameter --region us-east-1
what happens when you put quotes around url in the original request (note the '):
awscurl --service s3 'https://awscurl-sample-bucket.s3.amazonaws.com/?query=para:meter'
@okigan The problem still exists, same error as above.
Umm it's taking me down a memory lane. I think the issue is the tool does not know when to perform parameter quoting (and avoiding double quoting).
The RFC section https://datatracker.ietf.org/doc/html/rfc3986#section-2.4 was not helpful, but I am curious if there a definitive behavior that has been documented for this already.
My naive assumption as a user would be that the signature calculation would be done on the correctly url-encoded uri which is called and not on something which is not called :)