具有私人消息传递系统的CouchDB每用户数据库方案

Question

我想知道如何构建一个用户能够向其他用户发送消息的系统。当然，每个人都需要只能访问他的收件箱，因此我们需要每用户数据库基础设施。根据{{​​3}}的示例，我们看到用户可以将消息放入收件人的数据库中。简单而有效。

但是如果我们不想让用户知道收件人数据库名称呢？如果我们想要一个能够通过查看消息文档的到字段来解析收件人数据库的系统（可能是用户名，与他的数据库名称完全无关），该怎么办：

{
    "to": "john.kowalski",
    "from": "jake.podolski",
    "subject": "hi",
    "message": "..."
}

对于额外的等级来说，这似乎是一项完美的任务，但是它会没有乐趣而且不值得提问，所以我们将尝试通过复制来解决它：

1. 用户将消息文档放入主数据库
2. 复制任务（我们将为每个用户设置一项任务）使用筛选器来提取该文档，该筛选器按过滤_change 字段。名称“john.kowalski”将作为过滤器功能的参数传递。
3. 文档以收件人数据库结尾。

但是，这会产生问题，因为主数据库必须对所有用户可见！那么......如果我们能够添加用户 - >主要复制任务，那么这些消息将从用户数据库中传输到主数据库，然后放入收件人数据库（哦，主，它变得复杂了） ，我们可能已经浪费了我们的时间，试图用这种方式来解决它，但是试试吧。

1. 用户将消息文档放入其数据库
2. 复制任务提取该文档，但不能使用任何类型的过滤功能，因为此情况下的过滤器归用户所有，因此无法信任。
3. 主数据库验证文档 - 它检查来自字段的是否与源数据库关联。
4. 以前方法中使用的复制任务将文档传输给收件人。

此处第三步存在问题（如果没有该步骤，用户可以通过在 字段填写虚假信息来发送冒充任何其他用户的消息） - 我们如何能够传递其他数据到验证功能，据我所知，唯一的参数是：

• old doc
• 新文档
• 用户上下文（记录的用户名，角色，正在编写文档的数据库）
• 安全对象？

通过调用1.1.0中引入的复制器数据库功能，我们可以将user_ctx上下文传递给复制任务。这个对象是否可以包含自定义数据而不是真实的用户信息？这将如何影响CouchDB处理数据库访问的标准方式？

如果可以，复制任务只会在user_ctx下填充收件人名称作为参数，然后验证功能将使用该值与 字段进行比较。用户无法像以外的人那样“发送”消息。

Answer 1

你在这里做了一个很大的假设：

  

但是，这会产生问题，因为主数据库必须这样做   对所有用户都可见！

有一种替代解决方案可以避免让所有用户都看到主数据库。您可以让用户将消息文档保存到自己的数据库中，并设置过滤复制以将消息传输到主数据库，而不是让每个用户将消息文档直接放入主数据库。可以限制主数据库，以便应用程序的常规用户无法访问它。用户数据库和主数据库之间的复制需要由管理员启动，但这只需要为每个用户执行一次，因为复制任务在当前版本的CouchDB中是持久的。

Answer 2

您可以设置沙发，以便用户有权在数据库中读取和写入常规文档，但无法修改_design文档。这样您就可以信任用户数据库中的验证，除非它部署在用户站点，但是无论如何您都需要将数据复制到数据库中。我想我可以同意你的声明，它可以用工作任务完成:)。事实上，我认为它将是“Couch Way”，考虑到使用外部python脚本完成分片/聚类。

Answer 3

此问题类似于CouchDB user creation的问题。

与那个问题一样，我很乐观我的inbox database补丁会让这一切变得更好。