2013-02-24 84 views
4

我嘗試通過REST Api訪問Windows Azure存儲帳戶時遇到身份驗證問題。Windows Azure表REST Api身份驗證

我已閱讀以下資源,以確定如何生成的要求:只有4個在請求變量

http://msdn.microsoft.com/en-us/library/windowsazure/dd179428.aspx

http://convective.wordpress.com/2010/08/18/examples-of-the-windows-azure-storage-services-rest-api/

Azure Blob Service REST API returns 403 error: "Request date header not specified"

從我的理解: 確定服務端點的實際URI, GMT時間的當前日期 主要訪問密鑰 帳戶名稱。

我有兩個來自MSDN資源,另外兩個來自我的Windows Azure Portal。

GET http://<account_name>.table.core.windows.net/ HTTP/1.1 
x-ms-date: Sun, 24 Feb 2013 09:19:31 GMT 
x-ms-version: 2009-09-19 
Authorization: SharedKey <account_name>:<primary_key> 
Accept-Charset: UTF-8 
Accept: application/atom+xml,application/xml 
DataServiceVersion: 1.0;NetFx 
MaxDataServiceVersion: 1.0;NetFx 
Host: <account_name>.table.core.windows.net 

我檢查,以確保帳戶名和主鍵是正確的,而X-MS-日期戳是基於與其他職位的建議,在15分鐘內。

我會收到以下消息:

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: 437 
Content-Type: application/xml 
Server: Microsoft-HTTPAPI/2.0 
x-ms-request-id: d78c2c11-8699-4737-9592-82813eac356e 
Date: Sun, 24 Feb 2013 21:20:03 GMT 

<?xml version="1.0" encoding="utf-8" standalone="yes"?> 
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> 
    <code>AuthenticationFailed</code> 
    <message xml:lang="en-US">Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. 
RequestId:d78c2c11-8699-4737-9592-82813eac356e 
Time:2013-02-24T21:20:03.2036675Z</message> 
</error> 

上固定正確地認證的要求有什麼建議?

此外,我能夠下載Azure存儲資源管理器實用程序並以這種方式訪問​​服務,因此我知道存儲帳戶有效且正在工作。

回答

4

後一些更多的搜索,我發現下面的文章:

  1. http://msdn.microsoft.com/en-us/library/windowsazure/dd135720.aspx
  2. http://blog.einbu.no/2009/08/authenticating-against-azure-table-storage/

的基本結論是,SharedKeyLite必須用於這種類型的請求。

資源#1,它說:

表服務要求每個請求進行身份驗證。共享密鑰和共享密鑰Lite認證均受支持。共享密鑰身份驗證更安全,建議用於使用REST API對錶服務進行的請求。 用於WCF數據服務的Microsoft .NET客戶端庫僅支持共享密鑰Lite身份驗證。

一個資源#2說明了如何創建ShareKeyLite並在底部提到:

由於SharedKey比SharedKeyLite更穩健,這將是顯而易見的選擇。但是,我們仍然需要SharedKeyLite方案來訪問Development Table Storage,因爲它是唯一可以接受的方案。 (由於在Windows Azure SDK的七月CTP的。)

1

我有同樣的問題。我也下載了Azure存儲瀏覽器實用程序。我正在使用Fiddler Web Debugger來查看從天真到蔚藍的請求。要求是這樣的:

GET http://mystorageaccount.table.core.windows.net/Tables() HTTP/1.1 
User-Agent: Microsoft ADO.NET Data Services 
DataServiceVersion: 1.0;NetFx 
MaxDataServiceVersion: 2.0;NetFx 
x-ms-version: 2009-09-19 
x-ms-date: Tue, 26 Feb 2013 07:18:04 GMT 
Authorization: SharedKeyLite mystorageaccount:mystorageaccountkey 
Accept: application/atom+xml,application/xml 
Accept-Charset: UTF-8 
Host: mystorageaccount.table.core.windows.net 
+0

我做了同樣的事情,雖然它的工作原理並沒有真正解釋爲什麼原始請求失敗。 此外,它帶來了另外兩個問題: 1. SharedKey和SharedKeyLite有什麼區別? 這是我的理解ShareKeyLite只是基於用於生成哈希的信息的一個不太安全的SharedKey形式。 2.哪裏可以找到Windows Azure Portal中的SharedKeyLite? 我發現的所有內容都是位於底部功能區中的「管理密鑰」按鈕,同時查看存儲帳戶頁面。它只是通過執行base64手動生成的(sha1(something)) – 2013-02-27 06:36:28

+0

是的,馬特。天藍色的問題有很多... – DmitryBLR 2013-02-27 11:02:51

1

我在這裏打了同樣的錯誤AuthenticationFailed。對於表服務,這個錯誤沒有提供任何細節。只有通過反覆試驗才能看到來自其他網絡的代碼片段與我所做的不同之處 - 就是調試它的方法。

對於blob服務,我曾看到過提到的錯誤 - 服務器計算出的StringToSign(帶有值)和來自簽名的stringToSign不匹配。這幫助我修復了計算身份驗證頭的代碼。

更多詳細信息以及其他錯誤代碼,將永遠幫助開發人員。

回到問題,問題是需要x-ms-date標頭而不是'Date'標頭。所以,錯誤代碼放錯了位置。

對於winjs windows store應用程序。工作代碼看起來像這樣:

var url = 'https://<storageaccount>.table.core.windows.net/<table name>()'; 
var date = new Date().toGMTString().replace('UTC', 'GMT'); 
var xhrOptions = { 
    type: 'GET', 
    url: url, 
    headers: { 
     // Date: date, // does not work and raises AuthenticationFailed error 
     'x-ms-date' : date, // works 
     'Content-Type': 'application/atom+xml', 
     'x-ms-version': '2009-09-19', 
     DataServiceVersion: '1.0;NetFx', 
     MaxDataServiceVersion: '1.0;NetFx', 
    }, 
}; 

xhrOptions.headers.Authorization = computeAuthorizationHeader(xhrOptions);