3

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!

Community
  • 1
  • 1
Vlad Bilyk
  • 327
  • 4
  • 13
  • I started getting that when I switched from _self links to id-based link so I now passively cache _self links after the first time I fetch with id-based links. I still get the error sometimes but less and I have built in auto retry to hide it from my application code. Another thing that I changed about my system when I started seeing the problem was that my test system now creates a new database and collection every time the test starts and deletes it at the end. I wonder if the rapid and often creation/deleting is contributing to the problem. – Larry Maccherone Dec 25 '15 at 18:29
  • It is something DocumentDB needs to fix. I have sent them details of when I have gotten that so maybe they are working on it. After the holiday, someone from the team might contact you to get your details. That might help them zero in on it. – Larry Maccherone Dec 25 '15 at 18:30
  • I also have faced with the issue after switching to id-based links. – Vlad Bilyk Dec 26 '15 at 19:48
  • Hey there - I work on the DocumentDB team... Can you e-mail me w/ some more details: andrl {at} microsoft.com – Andrew Liu Jan 06 '16 at 19:13
  • A few things that will help: 1) What platform + version of the SDK are you using? 2) Does this happen intermittently or always? 3) Can you include an activity and timestamp for the exception? This will allow us to look for and trace a particular request in our logs. 4) Can you include a code snippet of what you are trying to do? – Andrew Liu Jan 06 '16 at 19:15
  • @AndrewLiu, I've sent the requested information by email. – Vlad Bilyk Jan 08 '16 at 00:27
  • @AndrewLiu, do you have any update? – Vlad Bilyk Jan 20 '16 at 11:26

4 Answers4

6

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.

Murilo Maciel Curti
  • 2,677
  • 1
  • 21
  • 26
5

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

Andrew Liu
  • 8,045
  • 38
  • 47
3

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

Jeberdson Abraham
  • 541
  • 7
  • 11
0

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

jeevan
  • 1