Signature Error for Query Containing Spaces Encoded as +
See original GitHub issueWhich service(blob, file, queue, table) does this issue concern?
Blob, but potentially others
Which version of the Azurite was used?
3.18.0
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
mcr.microsoft.com/azure-storage/azurite
What’s the Node.js version?
What problem was encountered?
As described in the URL standard spaces in a query string may be encoded as +
, and not %20
. This is what the standard Rust URL library will always do. As per the specification for Azure this will be URL-decoded as part of generating the canonical string to sign.
For example, GET http://localhost:10000/devstoreaccount1/tustvold?restype=container&comp=list&prefix=foo+bar%2F
would result in
GET
Wed, 28 Sep 2022 16:38:41 GMT
x-ms-version:2021-08-06
/devstoreaccount1/devstoreaccount1/tustvold
comp:list
prefix:foo bar/
restype:container
However, making this request to azurite returns a signature error. My guess is it is only percent decoding the query parameters and not url decoding them, and therefore ends up with a different string to sign.
The same request to a Azure proper succeeds
Steps to reproduce the issue?
Noticed in https://github.com/apache/arrow-rs/pull/2801, let me know if you need a more specific example
Have you found a mitigation/solution?
No
Issue Analytics
- State:
- Created a year ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
@tustvold Thanks for the info! I can repro it with shared key credential now.
It looks the problem is caused by decodeURIComponent() used in following line can’t pare “+” to space. https://github.com/Azure/Azurite/blob/24533376c9bb11ceef005eac5242738032f7196d/src/blob/authentication/BlobSharedKeyAuthenticator.ts#L311
I will look into it and update you later.
Thank you for the quick response, unfortunately the Rust URL library doesn’t provide a way to configure its escaping, at least as far as I’m aware.
We only use azurite for tests, and so I have just suppressed the test for this behaviour, and so there is no major rush from my end.