CouchDB在允许将对象/行插入数据库之前提供验证。这确保了如果你有一个面向公众的沙发应用程序，你的数据库将不会被任何人填充垃圾。
User <-> CouchDB
但是，我想知道从标准应用程序设计过程中出现的是trusted middle layer that does much of the auth work。例如，大多数应用程序将Ruby或PHP放在数据库和用户代理之间，这允许应用程序在允许将类似帖子的内容保存到数据库之前找出有关用户代理的信息。
User -> Ruby -> MySQL
User <- Ruby <- MySQL
当用户无法信任时，您如何信任用户执行管理任务？
例如，在使用couchDB插入用户行之前，您会如何做“电子邮件验证”？您不能让用户代理插入行 - 因为它们会向系统填充垃圾邮件帐户。另一方面，没有中间层可以在单击电子邮件中的链接后插入行。
这个怎么样，我会假设您允许任何人通过在公共表格email_verify中创建新记录来输入他们的电子邮件。这是公共用户代理可以执行的操作，因为表不会在应用程序中执行任何操作 - 它只是一个存储槽。
然后node.js可以跟踪_changes提要并发送激活电子邮件，同时在私有表中创建新条目（如email_confirm）（node.js将用作可信中间层）。如果用户单击该链接然后返回... [unknown] ...而node.js最终可以在私有用户表（user）中创建记录。
此时，我们可以依赖couchdb验证来完成应用程序的其余部分，因为我们已经创建了已确认的用户帐户。
随着更多背景让我们想象一下建立在couchdb上的讨论，任何人都可以注册。我们不希望任何人在没有某种验证的情况下直接提交内容 - 但用户代理所有直接运行系统。 （表格为Thread，Comment和＆amp; User）。这将如何运作？
答案 0 :(得分：3)
我会考虑在此问题中为现有用户添加角色。
当用户第一次使用时，使用couchdb的验证并更改_design/_auth，最好在email数据库中添加email_verified，email_verification_code和随机生成的_users寄存器。
要发送邮件，获取确认，重新发送确认即可使用外部流程。 （有关外部进程的示例用法，您可以检查couchdb-lucene）。
如果验证码匹配并为该用户添加verified_user角色，最后您可以再次在用户更新过程中快速检查_design / _auth。
这样您的所有请求都会通过couchdb传递，只有在需要发送邮件并获得确认时才会使用外部进程。
编辑：忘记添加（因为很明显），我会将verified_user角色添加到数据库读者。
答案 1 :(得分：1)
你能不能只使用CouchDb's Validation？
用户可以被举报。注册后，用户将添加到用户数据库。他收到了他的邮件，然后在回复邮件或点击链接时被标记为“有效：真实”或类似的东西。
通过验证，用户不仅可以“登录/退出”，还可以使用更细粒度的访问权限实现访问授权。例如：如果一个是作者，管理员，等等......只标记线程已解决。
或者这似乎不切实际？
答案 2 :(得分：1)
在与#couchdb IRC上的某些人交谈之后，他们似乎无法找到一种方法来做一些管理工作（比如点击电子邮件链接的激活用户）而不使用像“后端”这样的“后端”流程node.js服务器，用于跟踪_changes feed。
我希望有一个纯粹的couchdb应用程序 - 但似乎couchdb还有一些方法可以去。
但好消息是，您可以将80％的应用程序逻辑/处理交给用户。另外20％将是1）一个node.js实例，用于发送电子邮件或检查recaptcha，以及2）记录在couchdb中运行的验证函数，以及3）map / reduce（查询）函数。这三件事不能像用户代理那样被卸载到“不受信任的”。