2016-11-06 45 views
2

當我向我的couchdb服務器發送http請求時,如在文檔CouchDB Proxy Authentication中顯示的那樣,它不給出文檔中顯示的響應,只是空數據。我究竟做錯了什麼?CouchDB代理身份驗證不起作用

另外,我可以用這個代理身份驗證啓動會話嗎?如果我嘗試POST/_session,則會得到500個錯誤代碼。

GET/_session HTTP/1.1
主機:127.0.0.2:5984
的User-Agent:捲曲/ 7.51.0
接受:應用/ JSON
內容類型:應用/ JSON;字符集= UTF-8
X-AUTH-CouchDB的-用戶名:約翰
X-AUTH-CouchDB的-角色:博主

< HTTP/1.1 200 OK
<緩存控制:必須-重新驗證
<內容長度:132
<內容類型:應用程序/ JSON
<日期:太陽,2016年11月6日1時10分58秒GMT
<服務器:CouchDB的/ 2.0.0(二郎OTP/17)
< 「ok」:true,
「userCtx」:{「name」:null,「roles」:[]},
「info」:{「authentication_db」:「_ users」,「authentication_handlers」:[ cookie「,」default「]}}

回答

4

我在CouchDB問題跟蹤器中發現代理身份驗證在2.0.0版中被破壞。無論是該文件還是文檔都不會更新以表明它只適用於羣集或其他內容。我改回1.6.1版,一切正常。我必須說,代理驗證如何工作的文檔非常差。

它是如何工作的,你需要你的第三方認證服務器具有「[couch_httpd_auth]祕密」,當客戶端認證時,你需要通過組合用戶名和密碼來生成HMAC-SHA1令牌。然後,在任何HTTP請求從客戶端做出CouchDB的服務器,如果包括所有的頭:

  • X-Auth-CouchDB-Roles
  • X-Auth-CouchDB-UserName
  • X-Auth-CouchDB-Token

該請求將被認證爲一個用戶客戶端。

此外,它沒有在文檔中提到,但POST上的/_session API使用這些標頭什麼也不做。

+1

似乎在2.1.0中修復 - https://issues.apache.org/jira/browse/COUCHDB-3203 –

+1

它在2.1.0中修復,但文檔不正確地引用舊的[httpd]部分。您現在必須在[chttpd]下進行配置。 –

+0

在安全性方面是否允許用戶在標題中傳遞角色時是否違反了規定?爲什麼他不能通過'管理員'?謝謝 –

3

這不是代理認證本身,它在CouchDB 2.0中被破壞,它只是在當前版本中沒有辦法配置認證處理程序,就像在過去1.6天內那樣。

問題跟蹤器中提到了一些補丁,它將代理驗證添加到驗證處理程序列表中。此外,還有一個被接受和合並的拉取請求,這可以提高CouchDB 2.0的可配置性。

但是,爲了充分利用這些功能,恐怕您必須等到下一個版本,或者從源代碼構建CouchDB 2.0。

+0

啊謝謝你的解釋。我也這麼想,因爲無論我將哪個認證處理程序放在local.ini中,它總是隻迴應cookie和默認值。 –

+2

請注意,所提到的拉回請求帶來的可配置性,現在是最新官方2.1版本的一部分。 – dmunch

+0

@dmunch默認情況下是否需要其祕密? – joeforker