CouchDB和Cloudant安全

Question

我們在生產中使用了CouchDB，主要是在受控環境中構建應用程序。大多數情況下，我們使用中間件庫直接調用couchdb/cloudant，因此避免直接（前端JavaScript調用直接調用CouchDB/Cloudant）。

出於安全原因，很明顯，通過身份驗證的CouchDB數據庫：
http://{username}:{password}@IPAddress:Port/DB
OR爲cloudant：
https://{username}:{password}@username.cloudant.com/DB， 如果呼叫直接從JavaScript做，今天在瀏覽器的開發者工具，使一個人認識到這一點調用並因此完全訪問您的數據庫。

在中間件處理時，附件通常很痛苦。使雲霧處理附件的緩存和服務直接到達前端是有利的，因此減輕了我們的中間件的負擔。然而，在網絡上和大量的觀衆中，直接打電話給我們的雲環境是棘手的。

我們首先爲所有附件擁有一個獨立的cloudant帳戶，因此inquisitive boy不會篡改實際的元數據或我們用戶的信息。因此，他們可以訪問的唯一雲帳戶是附件，因爲我們正在對數據庫進行直接的JavaScript調用。

問題：我們如何找到隱藏我們的雲環境的用戶名和密碼的方式，從而使我們能夠安全地直接將JavaScript調用到cloudant上？我們的基礎設施完全在雲端，所以我們沒有代理和東西可以使用。我們聽說過Url縮短服務，CDNs e.t.c.但是，我們還沒有提出一個確鑿的解決方案。

Answer 1

嘗試使用_session端點。這將設置cookie認證。

Answer 2

我們如何找到一種隱藏雲端環境的用戶名和密碼的方式，從而使我們能夠安全地直接將JavaScript調用到雲端？

據我所知，如果不使用中間件或某種代理服務器，就無法做到這一點。但這並不意味着我們完全沒有手段。 couchdb給我們一些矛戳inquisitive boy :)

所以你做的一件好事是讓附件數據庫分離。你沒有提到你的問題，如果你使用couchdb授權方案，所以我會假設你不是。因此，第一步是在couchdb _users數據庫中創建一個用戶，然後將其分配爲附件數據庫中的成員。更多詳情here和here。

完成此步驟後，您應該有一個附件數據庫成員。我們希望成員而不是管理員的原因是，成員無權編寫或閱讀設計文檔。

這是一個開始，但它還不夠，因爲成員仍然可以通過_all_docs讀取，這是一個dos攻擊。所以我們現在面臨的問題是，我們現在這樣做

https：// {username}：{password} @ username.cloudant。COM/DB

一個很好的舉動將其更改爲

的https：// {用戶名} {}密碼@ someurl.com/

有什麼區別這兩個之間？那麼它會隱藏你的數據庫的位置，並使訪問內置方法變得更困難。這可以在vhosts configuration和some rewrite rules的幫助下完成。一些very good stuff也在Caolan的博客上

有了這個，你有兩件事情要做。

1. 的死纏爛打inquisitive boy將是毫無章法，其中電話去。

2. 他將無法通過直接調用獲取未知文檔的內容。他只能通過您設置的規則訪問您的數據庫。

仍然不是100％安全，但只要讀取安全等級就可以了。希望這可以幫助。