CODEWITHSUNDEEP
azureazure-cosmosdbazure-sdk-.net
Vlad Bilyk
Vlad Bilyk

Reputation: 327

DocumentDB UnauthorizedException: "The MAC signature found in the HTTP request is not the same as the computed signature."

Sporadically I had UnauthorizedException when requesting the documents from DocumentDB. The issue looks similar to Azure DocumentDB - The MAC signature found in the HTTP request is not the same as the computed signature, so I believe that problem is not solved.

Microsoft.Azure.Documents.UnauthorizedException : 
Message: "The MAC signature found in the HTTP request is not the same as the computed signature. 
Request URI: rntbd://db5prdddc01-docdb-1.documents.azure.com:14245/apps/35e0fabb-e03e-48d4-90ad-7b91b63c0153/services/9bb95f7b-9ad6-4128-a66a-de68279d5124/partitions/44a24d42-a85c-42cc-98c4-fc8a733245ac/replicas/130953283548138839p/

UPDATE: The issue was fixed, special thanks to Andrew Liu!

Upvotes: 3

Views: 6976

Answers (4)

jeevan
jeevan

Reputation: 1

We could able to resolve the issue with below workaround :

In Azure Portal -> Azure Cosmos DB for MongoDB -> -> Connection strings, there will be

  1. Read-write Keys
  2. Read-only Keys

if getting error while reading add use PRIMARY CONNECTION STRING in Read-only Keys. if getting error while writing add use PRIMARY CONNECTION STRING in Read-write Keys.

use it based on what your application are doing

Upvotes: 0

Jeberdson Abraham
Jeberdson Abraham

Reputation: 561

I faced the same problem while I used the primary connection string, when I changed the connection string to secondary, it worked for me.

enter image description here

Upvotes: 3

Murilo Maciel Curti
Murilo Maciel Curti

Reputation: 3121

Check for static client method. Is possible that you are using a client with a Read-only Key by mistake.

Trying to write using a Read-only Key throws that exception.

Upvotes: 7

Andrew Liu
Andrew Liu

Reputation: 8119

Happy to hear you are no longer experiencing this issue :)

Posting here for everyone else's benefit...

If you see an issue like this, it means that there is an authentication header mismatch between the application and database. This can be a result of many things... including an incorrect auth key, system clocks out of sync, or an issue with how the auth header is generated.

First-Party DocumentDB SDKs

If you are using one of DocumentDB's 1st party client SDKs - it's most likely an incorrect auth key or a system clock issue...

If those look good, than there is a bug on DocumentDB's end. If you are experiencing issues - please contact me (askcosmosdb {at} microsoft.com) with a few activity ids + timestamps + stacktrace, and I can help you look in to the issue.

Rest API

The header is rather tricky to put together... Here are some tips for constructing the auth header:

  • All parameters (verbs, resource type, date, etc.) must be lower case prior to signing EXCEPT when using id-based routing.

  • For id-based routing, you will need to sign the full path to the resource (e.g. dbs/MyDatabase/colls/MyCollection/docs/MyDocument); not just the resource's id (e.g. MyDocument). Please note that the path is case-sensitive... while, all the other parameters should be lower case.

  • The key is Base64 encoded.

  • The text to be signed should be utf-8 encoded.

  • The generated auth token is a SHA256 HMAC and should be Base64 encoded.

  • As with all HTTP headers, the signature (including the signed token) should be URL encoded (e.g. + needs to be encoded as %2B).

Full documentation and sample code, see: https://msdn.microsoft.com/en-US/library/azure/dn783368.aspx

Upvotes: 5

Related Questions