Describe the bug
Azure seems to sort metadata keys containing underscores differently, causing a AuthenticationFailed error.
In the example below the metadata keys are: i0 and i_. Lexicographically, i0 < i_, but in the Azure response (in the canonicalized request) i_ is placed before i0.
To Reproduce
blob_service_client = BlobServiceClient(
account_url="http://<...>.blob.core.windows.net",
credential="<...>"
)
blob_client = blob_service_client.get_blob_client('mybucket', 'blob')
blob_client.upload_blob(
'',
metadata={
'i0': 'a',
'i_': 'a',
})
Creates the following HTTP request:
PUT /mybucket/blob HTTP/1.1
Host: <...>.blob.core.windows.net
x-ms-version: 2019-07-07
Accept-Encoding: gzip, deflate
x-ms-blob-type: BlockBlob
Content-Length: 0
Accept: */*
User-Agent: azsdk-python-storage-blob/12.2.0 Python/2.7.17 (Linux-5.5.8-arch1-1-x86_64-with-Ubuntu-18.04-bionic)
Connection: keep-alive
x-ms-client-request-id: 9386d62c-6474-11ea-a2cd-0242ac130002
x-ms-meta-i_: a
x-ms-meta-i0: a
If-None-Match: *
Content-Type: application/octet-stream
Authorization: SharedKey <...>:<...>
x-ms-date: Thu, 12 Mar 2020 15:17:24 GMT
And Azure responds with the following error:
HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
Content-Length: 809
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: d5cab1f8-801e-002e-6f81-f81f83000000
x-ms-error-code: AuthenticationFailed
Date: Thu, 12 Mar 2020 15:17:24 GMT
...<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:d5cab1f8-801e-002e-6f81-f81f83000000
Time:2020-03-12T15:17:24.4950608Z</Message><AuthenticationErrorDetail>The MAC signature found in the HTTP request '<...>' is not the same as any computed signature. Server used following string to sign: 'PUT
application/octet-stream
*
x-ms-blob-type:BlockBlob
x-ms-client-request-id:9386d62c-6474-11ea-a2cd-0242ac130002
x-ms-date:Thu, 12 Mar 2020 15:17:24 GMT
x-ms-meta-i_:a
x-ms-meta-i0:a
x-ms-version:2019-07-07
<...>'.</AuthenticationErrorDetail></Error>
Expected behavior
The code above should execute without problems.
Thanks @bno1 for reaching out, tagging the right team to take a look at this // cc: @xgithubtriage
@xiafu-msft can you please investigate, also make sure that this does not happen in Java, .Net and JS.
Is it possible that this might be a server bug? I can't see any reason for the server to sort i_ before i0 unless it transforms the key somehow, for example removing _ and other special characters. The same thing happens if you use ^ instead of _: lexicographically i0 < i^, but Azure sorts them the other way around.
The only documentation that I could find about metadata keys is: [1], stating that "Metadata names must adhere to the naming rules for C# identifiers.". I'm not familiar with C#, but I would expect _ to be supported inside identifiers, as it is in most programming languages. On the other hand, I don't think ^ is acceptable inside identifiers, yet the server accepts i^.
Hi @bno1
Thanks so much for reaching out with the detailed reproduce steps!
I was able to reproduce the bug. I have reached out service people and I will get back to you by the end of tomorrow!
Hi @bno1
We have confirmed it's a bug which is because service is using word-sorted Sort() while the SDK is not assigning weight to characters when doing sort.
We will track the bug and fix in the future.
Sorry about the inconvenience and hope it's not blocking you.
@xiafu-msft thanks for the assistance! This bug is not a big problem for me.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.
Any update on this issue?
I am getting the same AuthenticationFailed error using set_blob_metadata(metadata) from the SDK (Python version 3.7.6). My keys are all Camel Case alphas and do not contain underscores.
Hi @mikeclymer
sorry that we haven't got time to work on this, but it's in out backlog! Sorry about the inconvenience....
We are actively working on this now!
Hi @dadbrains and @bno1,
I have just put a PR addressing this issue! Hopefully the fix will be released soon :)
I'll keep you updated!
Most helpful comment
@xiafu-msft thanks for the assistance! This bug is not a big problem for me.