Meteor “理解”；不允许。不受信任的代码只能按ID更新文档。”；流星误差

在这方面，引入了以下变化：

在不受信任的代码中调用update和remove集合函数 可能不再使用任意选择器。您必须指定一个 从客户端调用这些函数时的文档ID（除 在方法存根中）

因此，现在如果要从客户端控制台向数据库推送任意更新，必须执行以下操作：

People.update({_id:People.findOne({name:'Bob'})['_id']}, {$set:{lastName:'Johns'}});

而不是：

People.update({name:'Bob'}, {$set:{lastName:'Johns'}});

我认为这个安全问题是通过设置Meteor.Collection.allow和.deny函数以及自动发布和不安全的包来控制的。我喜欢能够从Chrome JavaScript控制台与db交互

Meteor 0.5.8的变化动机是什么

允许/拒绝规则的更改 从0.5.8开始，仅客户端代码（如事件处理程序）一次只能更新或删除由_id指定的单个文档。方法代码仍然可以使用任意Mongo选择器一次操作任意数量的文档。要从事件处理程序运行复杂的更新，只需使用Meteor.methods定义一个方法并从事件处理程序调用它

此更改显著简化了允许/拒绝API，鼓励改进应用程序结构，避免了潜在的DoS攻击，在这种攻击中，攻击者可能会迫使服务器进行大量工作以确定操作是否得到授权，并修复了@jan glx报告的安全问题

要更新代码，请将允许和拒绝处理程序更改为获取单个文档而不是文档数组。这将大大简化您的代码。还要检查是否在使用Mongo选择器的事件处理程序中有任何更新或删除调用（这是非常罕见的），如果有，请将它们移动到方法中。有关详细信息，请参阅和文档

因此，从我的观点来看，基本上，您永远不希望该行为能够在没有任何特定知识（如文档id）的情况下从客户端更新和删除任意文档集

当我猜测你正在做的是原型设计时——我想它可能会妨碍你，但是如果你想让你的代码投入生产，我相信利大于弊。这也归结为安全声明（

allow

和

deny

）在更改后更易于指定

---

希望这能为您提供更多信息。

几周前，我刚开始阅读一些较小的在线流星教程，并注意到它们的更新/删除示例中存在错误。今天晚上，我开始阅读“GettingStartedwithMeteor.jsJavaScript框架”，它也有第一个使用不再工作的删除的示例。为他们编写关于仍处于预览阶段的框架的书籍提供了合适的服务：）只是开玩笑，到目前为止，它看起来像是一本很棒的书。人们只能期待它不会与如此快速发展的框架同步，即使它在2012年12月刚刚发布。