-
-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signature mismatch on non url-encoded uris #115
Comments
what happens when you put quotes around url in the original request (note the '):
|
@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 :) |
It’s not clear if url already was percent-encoded (just applying would break other users I think)
Let’s me know if you see a robust way of implementing it.
… On Jun 8, 2021, at 4:16 AM, Dennis Jekubczyk ***@***.***> wrote:
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 :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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:meter
Results in an error:
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
The text was updated successfully, but these errors were encountered: