Meteor 我必须在Collection.allow和Collection.deny中包含什么逻辑才能确保它'；安全吗？

所以我开始玩Meteor，试着了解一下安全模型。似乎有两种方法可以修改数据

Meteor.call方式看起来相当标准——几乎只是对服务器的调用，并实现了自己的一组业务规则

然后是Collection.allow方法，它似乎与我以前做的任何事情都大不相同。因此，如果您放置一个collection.allow，您的意思是客户机可以对该集合执行任何写入操作，只要它能够通过其allow函数中的验证

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

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

对于可能对您的系统进行的每种类型的更新，您是否也必须输入业务逻辑

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

在我看来，你必须把所有的东西都放在这个巨大的函数中。这听起来是一个激进的想法，但似乎Meteor.call方法会简单得多

---

我是否以错误的方式（或针对错误的用例）思考此问题？是否有人有任何示例，说明他们可以如何构造允许或拒绝函数，并列出我可能需要在允许函数中检查的内容，以确保我的收藏安全？

我通常使用的

允许
方法有：

MyCollection.allow({
插入：假
更新：false
删除：false
})

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


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

看一看。它们支持在将文档插入集合之前在运行时进行模式检查。
您遵循的推理与我在构建Edthena时决定如何处理数据突变时使用的推理相同。meteor为您提供了现成的工具，可以进行简单的权衡：

我是否信任客户机并获得响应更快的UI（延迟补偿）？或者我需要严格控制数据验证，但强制客户机等待更新

我选择后者，并且出于以下几个原因专门使用方法调用：

知道有一种方法可以更新我的每一个收藏，我晚上睡得更好
我发现我的一些更新需要副作用，这些副作用只有在服务器上执行才有意义（例如，对其他集合进行非规范化更新）
目前，我们的应用程序没有明显的延迟补偿优势。我们发现大多数写操作的延迟对用户体验无关紧要
allow
和
deny
规则是很弱的工具。它们基本上只适用于验证所有权和其他简单检查
在我们第一次投入生产时（2013年8月），这似乎是一个激进的结论。meteor文档、API和演示突出了客户端写入的使用，因此我不能完全确定我是否做出了正确的决定。几个月后，我第一次有机会与几个meteor core开发人员坐下来——这是他们对我的设计选择的反应总结：

这似乎是一种理性的做法。延迟补偿在某些情况下非常有用，如移动应用程序和游戏，但对于所有web应用程序可能不值得。它还可以制作很酷的演示

好了。在撰写本文时，我对生产应用程序的建议是，在您真正需要速度的地方使用客户端更新，但您不应该因为大量使用方法而感觉自己做错了什么

至于未来，我认为在1.0之后，我们将开始看到客户端和服务器上的内置模式实施，这将大大有助于解决我的问题。我认为这是朝着这个方向迈出的重要的第一步，但我还没有以任何有意义的方式尝试过


存根
一个合乎逻辑的后续问题是“为什么不使用存根？”。我花了一些时间对此进行调查，但得出结论，方法存根对我们的项目没有用处，原因如下：

我喜欢将我的服务器代码保存在服务器上。stubing要求我要么将所有模型代码发送给客户机，要么有选择地再次重复部分模型代码。在大型应用程序中，我认为这并不实用
我发现，将客户机上可能运行或不运行的内容分离出来所需的开销是一项维护挑战
为了让存根除了拒绝数据库变异之外还能做任何事情，您需要有一个允许规则——否则最终会导致大量UI闪烁（客户端允许写入，但服务器会立即使其无效）。但是拥有一个allow规则就不能解决这一点，因为用户仍然可以从控制台向数据库写入数据
我也这么做，发现这是最可靠和最可预测的方法。所以基本上你是说你不使用Collections.allow和Exclusive使用Meteor.call方法？这正是我所倾向的，但Meteor将其作为其主要功能之一，所以我只想看一个真实的例子，说明这比使用Meteor更实用。顺便说一下，如果你要这样做，