meteor - 我必须在 Collection.allow 和 Collection.deny 中涵盖哪些逻辑以确保其安全？

Question

所以刚开始玩 Meteor 并试图了解安全模型。似乎有两种方法可以修改数据。

Meteor.call 方法看起来很标准——几乎只是调用服务器并实现了自己的业务规则集。

然后是 Collection.allow 方法，它似乎与我以前做过的任何事情都大不相同。所以看起来如果你放置一个 collection.allow，你是说客户端可以对该集合进行任何写操作，只要它可以通过其允许函数中的验证。

这让我感到不安，因为它感觉像是很大的自由，而且我的允许功能需要很长时间才能确保它足够安全地锁定。

例如，mongodb 没有模式，因此您基本上必须有一个规则来定义将接受哪些字段以及这些字段必须采用的格式。

您是否还必须为可能对您的系统进行的每种类型的更新都放入业务逻辑。

所以说，我有一个 SoccerTeam 收藏。可能有几种情况我可能需要进行更改，例如添加或删除球员、更改团队名称、团队状态已更改等。

在我看来，您必须将所有内容都放入这个庞大的函数中。这听起来像是一个激进的想法，但似乎 Meteor.call 方法会简单得多。

我是否以错误的方式(或错误的用例？)考虑这个问题？ 有没有人有任何示例说明他们如何构建允许或拒绝函数，并列出我可能需要在允许函数中检查的内容列表收藏安全吗？

Answer 1

平常的 allow我有这些方法:

MyCollection.allow({
    insert: false
    update: false
    remove: false
})

然后，我有处理所有插入的方法。这些方法执行类型检查和权限评估。我发现这是一种更易于维护的方法:将数据层与在客户端上运行的代码完全分离。

For instance, mongodb has no schema, so you'd have to basically have a rule that defines which fields would be accepted and the format those fields must be in.

看看 Collection2 .在将文档插入集合之前，它们支持在运行时进行模式检查。