Azure DocumentDB - 在 HTTP 请求中找到的 MAC 签名与计算签名不同
Azure DocumentDB - The MAC signature found in the HTTP request is not the same as the computed signature
似乎是随机的，我无法从 DocumentDB 获取文档。我可以调试，让它失败并显示以下消息，然后重试并开始工作。如果这与我的 MAC 地址有关，我也尝试从不同的工作站获得相同的结果。
Microsoft.Azure.Documents.UnauthorizedException, message:
{"Errors":["The MAC signature found in the HTTP request is not the
same as the computed signature. Server used following string to sign -
'post\ndocs\nmo1oanohoga=\nwed, 25 feb 2015 12:35:57 gmt\n\n'"]}
我该如何着手 a) 报告此事和 b) 试图弄清楚发生了什么？
您能否检查一下您的系统时钟时间与错误消息返回的时间是否有显着差异（< 5 分钟或大于 20 分钟）？由于时钟偏移，可能会返回此错误。如果是这种情况，更新您的时钟时间可能会解决此问题。
DocumentDB 客户端使用主密钥和请求的时间戳构造消息验证码(MAC) 以验证请求。出于安全原因，该服务拒绝 MAC 短时间内 window 的请求。
我们已确认这是一个仅限于北欧地区的问题。
我们正在对受影响的已知帐户应用修补程序，并将很快部署修复程序。
如果您不在北欧并且遇到了这个问题，或者如果您在收到此回复后的 2-3 天内继续查看，请再次与我们联系，以便我们进行进一步调查。
1.9 版本的 SDK 中似乎有一个特殊的回归，可能会导致引发此错误。我明白这与原来的问题无关，但如果你搜索这个错误，你就会来到这里，所以我认为 post 它是一个合适的地方。
此（错误）代码将在 SDK 1.8 和 1.9 中给出不同的错误消息：
docClient.CreateDocumentCollectionQuery(
UriFactory.CreateDocumentCollectionUri(DbName, CollectionName))
.Where(c => c.Id == CollectionName).ToList().Any()
在 1.8 中，您将正确获得 ResourceType Collection is unexpected。
在1.9你会得到The MAC signature found in the HTTP request is not the same as the computed signature. Server used following string to sign...
出于某种原因，它看起来像 1.9 returns 错误的错误消息（OP 引用的错误消息），但由于它完全具有误导性，您将很难找到问题所在。
说清楚；我 post 编辑的代码是 错误的 。我解释的问题是SDK version 1.9 returns错误的错误信息。
我遇到了同样的问题。但错误是我的。
为了修复，我更改了 Uri 方法。
之前：
this._documentCollectionUri = UriFactory.CreateDocumentUri(this._dataBaseName, this._collectionName, this._dataBaseName);
现在：
this._documentCollectionUri = UriFactory.CreateDocumentCollectionUri(this._dataBaseName, this._collectionName);
缺乏关注或关心
flw
我之前的回答被删除了（我相信，误会或误解...）
您可以检查您是否正在尝试使用只读密钥提交写入操作。
尝试使用只读密钥写入会引发该异常。
如果您使用静态 class 或方法来生成图形客户端，则可能是您使用了使用只读密钥的错误客户端实例。
似乎是随机的，我无法从 DocumentDB 获取文档。我可以调试，让它失败并显示以下消息，然后重试并开始工作。如果这与我的 MAC 地址有关，我也尝试从不同的工作站获得相同的结果。
Microsoft.Azure.Documents.UnauthorizedException, message: {"Errors":["The MAC signature found in the HTTP request is not the same as the computed signature. Server used following string to sign - 'post\ndocs\nmo1oanohoga=\nwed, 25 feb 2015 12:35:57 gmt\n\n'"]}
我该如何着手 a) 报告此事和 b) 试图弄清楚发生了什么？
您能否检查一下您的系统时钟时间与错误消息返回的时间是否有显着差异（< 5 分钟或大于 20 分钟）？由于时钟偏移，可能会返回此错误。如果是这种情况，更新您的时钟时间可能会解决此问题。
DocumentDB 客户端使用主密钥和请求的时间戳构造消息验证码(MAC) 以验证请求。出于安全原因，该服务拒绝 MAC 短时间内 window 的请求。
我们已确认这是一个仅限于北欧地区的问题。 我们正在对受影响的已知帐户应用修补程序，并将很快部署修复程序。
如果您不在北欧并且遇到了这个问题，或者如果您在收到此回复后的 2-3 天内继续查看，请再次与我们联系，以便我们进行进一步调查。
1.9 版本的 SDK 中似乎有一个特殊的回归，可能会导致引发此错误。我明白这与原来的问题无关，但如果你搜索这个错误，你就会来到这里，所以我认为 post 它是一个合适的地方。
此（错误）代码将在 SDK 1.8 和 1.9 中给出不同的错误消息：
docClient.CreateDocumentCollectionQuery(
UriFactory.CreateDocumentCollectionUri(DbName, CollectionName))
.Where(c => c.Id == CollectionName).ToList().Any()
在 1.8 中，您将正确获得 ResourceType Collection is unexpected。
在1.9你会得到The MAC signature found in the HTTP request is not the same as the computed signature. Server used following string to sign...
出于某种原因，它看起来像 1.9 returns 错误的错误消息（OP 引用的错误消息），但由于它完全具有误导性，您将很难找到问题所在。
说清楚；我 post 编辑的代码是 错误的 。我解释的问题是SDK version 1.9 returns错误的错误信息。
我遇到了同样的问题。但错误是我的。
为了修复，我更改了 Uri 方法。
之前：
this._documentCollectionUri = UriFactory.CreateDocumentUri(this._dataBaseName, this._collectionName, this._dataBaseName);
现在：
this._documentCollectionUri = UriFactory.CreateDocumentCollectionUri(this._dataBaseName, this._collectionName);
缺乏关注或关心
flw
我之前的回答被删除了（我相信，误会或误解...）
您可以检查您是否正在尝试使用只读密钥提交写入操作。 尝试使用只读密钥写入会引发该异常。
如果您使用静态 class 或方法来生成图形客户端，则可能是您使用了使用只读密钥的错误客户端实例。