方法

Question

在Meteor中，我应该何时更喜欢method而不是deny规则？

在我看来，allow / deny规则应该受到青睐，因为他们的目标更明确，并且知道在哪里寻找它们。

但是，在Discover Meteor一书中，防止重复插入（“重复”被定义为添加其url属性已在同一集合的某个其他文档中定义的文档）被认为必须定义通过一种方法（并留给读者练习，第8.3章）。

我想我能够以一种我更清楚的方式实施这项检查：

Posts.deny({
    update: function(userId, post, fieldNames, modifier) {
        return Posts.findOne({ url: modifier.$set.url, _id: { $ne: post._id } });
    }
});

（N.B。如果你知道这个例子，是的，我自愿省略了“只修改了属性的一个子集”，从问题中检查更具体。）

据我所知，Mongo还有其他update operators而不是$set，但它们看起来是打字的，我不想让安全漏洞开放。

那么：deny规则中是否存在任何缺陷？独立一下，我应该赞成一种方法吗？我会从中获得什么？我会失去什么？

Answer 1

通常我会尽量避免主观回答，但这是一个非常重要的辩论。首先，我建议您阅读Discover Meteor博客中的Meteor Methods vs Client-Side Operations。请注意，在Edthena，我们专门使用方法的原因应该是显而易见的。

方法

亲

方法可以正确实施任意复杂度的架构和验证规则，而无需外部库。附注 - check是验证输入结构的绝佳工具。
每种方法都是您应用程序中的单一事实来源。如果您创建'posts.insert'方法，则可以轻松确保它是您的应用中插入帖子的唯一方式。

CON

方法需要一种命令式样式，并且它们往往与操作所需的验证次数相关。

客户端操作

亲

allow / deny有一个简单的声明式风格。

CON

验证update操作的架构和权限是非常困难的。如果您需要强制执行架构，则需要使用外部库，如collection2。仅此原因应该让你停下来。
修改可以遍布整个应用程序。因此，确定特定数据库操作发生的原因可能很棘手。

摘要

在我看来，allow / deny在美学上更令人愉悦，但它的根本弱点在于强制执行权限（特别是在更新时）。在以下情况下我会建议客户端操作：

您的代码库相对较小 - 因此很容易为所有发生特定修饰符的实例进行grep。
您没有很多开发人员 - 所以您不需要都同意只有一种方法可以插入到 X 集合中。
您有简单的权限规则 - 例如只有文档的所有者才能修改它的任何方面。

在我看来，在构建MVP时使用客户端操作是一个合理的选择，但我会切换到所有其他情况的方法。

更新2/22/15

Sashko Stubailo创建了proposal to replace allow/deny with insert/update/remove methods。

更新6/1/16

流星指南的位置为allow/deny should always be avoided。

流星方法与拒绝/允许规则

1 个答案:

方法

亲

CON

客户端操作

亲

CON

摘要