【问题标题】：How to handle users in `_users` database with many applications in the same CouchDB instance?如何在同一个 CouchDB 实例中处理具有多个应用程序的 `_users` 数据库中的用户？
【发布时间】：2015-10-31 00:41:40
【问题描述】：
根据 Matt Woodward 的博客，在 The Definitive Guide to CouchDB Authentication and Security 中，他指出了一些关于 CouchDB 的事情，我不确定我是否完全理解。
-
他说：
“基本上，CouchDB 中的安全工作方式是将用户存储在_users 数据库中（或者如果您愿意，可以在其他位置；这可以在配置文件中更改）...”。
所以，整个 CouchDB 的所有用户都存储在一个数据库中，对吧？这意味着如果我在同一个 CouchDB 的不同数据库中运行多个应用程序，我必须处理想要访问这两个应用程序的用户，对吗？
-
他也说
“数据库读取者只能读取特定数据库上的文档和视图，没有其他权限”。
然后，他补充说
“默认情况下，所有数据库都为匿名用户启用读/写，即使您在数据库上定义了数据库管理员”。
那么匿名用户可以或不可以读取特定数据库中的文档吗？
【问题讨论】：
标签：
javascript
authentication
authorization
couchdb
nosql
【解决方案1】：
我首先要说的是，这些文章虽然内容丰富，但已有数年历史，可能已经过时。如果您想了解 CouchDB，我建议您阅读 official documentation。
现在回答你的问题。 （更多关于安全here和here的信息）
在 CouchDB 中，您可以在开发应用程序时逐步建立安全性。默认是非常开放的，你可以通过添加配置来锁定。 （我认为这是一种非常直观的方式）
默认情况下，CouchDB 处于“Admin Party”模式，这意味着任何人都可以读写任何内容。 （因为每个用户，包括匿名用户，都被视为管理员）
一旦您将 任何 管理员用户添加到您的服务器，（通过配置，而不是 _users 数据库）派对就结束了。这意味着某些操作现在只能由您明确定义的管理员执行。 （如创建数据库、设置配置等）
在这种状态下，匿名用户仍然可以在任何已创建的数据库中读取/写入普通文档。 （设计文档只能由管理员修改）如果您准备开始锁定单个数据库，您可以通过在给定数据库的 security object 中指定用户/角色来做到这一点。
当人们使用术语“数据库阅读器”时，他们的意思是用户已被添加为安全对象中的“成员”。 （通过他们的用户名或他们的角色）通过在数据库的安全对象中指定任何成员或管理员，那么只有这些用户将拥有数据库内部的权限，所有其他用户都将被禁止。
总而言之，匿名用户默认可以读/写任何东西。一旦指定了管理员，安全性就会加强，某些操作只能由该管理员执行。如果您指定数据库成员/管理员，则数据库的安全性会更加严格，仅允许这些用户甚至读取数据库。