是否存在CouchDB授权就足以满足生产应用程序的情况？他们建议在Couch前面部署代理服务器，但不建议授权层/服务器？请参阅Best Practices。我理解读访问是每个数据库的全部或没有。一个立即出现在脑海中的问题是-什么阻止用户或成员创建无限数量的数据库？设计（或验证）文档似乎无法查询现有DB的数量？其他问题也存在。下面是我能找到的所有官方文件。
这不是一个基于观点的问题，因为Couch可以在生产中单独存在，或者它不能假设开发人员遵循 * 最小权限访问原则 *。
CouchDB recommends使用HAProxy作为负载均衡器和反向代理。该团队在生产中使用它的经验表明，它在配置和监控功能以及整体性能方面都非常上级。
1.1.5.安全和验证
为了保护谁可以读取和更新文档，CouchDB有一个简单的读取器访问和更新验证模型，可以扩展该模型以实现自定义安全模型。
1.5.3.授权
CouchDB服务器上的每个数据库都可以包含自己的一组授权规则，这些规则指定哪些用户可以读取和写入文档成员，哪些用户可以读取所有文档以及创建和修改任何文档
4.1.5.使用半透明数据库添加客户端安全性
可以使用适量的加密和单向函数来隐藏敏感列或键值对，这种技术通常称为半透明数据库。
1条答案
按热度按时间tjrkku2a1#
不，CoucbDB没有您习惯在其他数据库中使用的安全系统。人们使用的方法有很多，这里只有一个：
在我工作的一家公司，我们有一个产品，为许多学校提供内容。学校为访问某些内容付费。
我们有一个数据库，它是我们的“全球”真相来源，它有所有学校的所有内容。它在自己的CouchDB服务器上，无法从互联网访问。
然后，我们有了一个面向学校的服务器，每个学校都有一个数据库。数据库使用随机UUID命名，并且这些DB只包括学校购买的内容（基于查询的过滤复制-过滤器使用UUID）。
因此，学校的设备上有自己的Couchbase-Lite DB，并被配置为使用UUID从面向学校的服务器本地复制学校特定的DB。
我想我们也有一个
validate_doc_update，只是为了防止教师更新他们不应该更新的数据。大部分都是在应用程序UI中处理的，数据库方面只是作为备份（主要是为了保护我们免受应用程序bug的影响）。值得注意的是，我们还有一些普通的基于RDBMS的Web应用程序，供学校管理人员做其他我们不感兴趣的事情，这些事情需要关系/事务机制。
所以这只是一个用例，显然有很多不同的方法来剥皮这只猫。