为什么使用Collection.allow而不仅仅是Meteor.methods和Meteor.call来实现这些方法?

dek*_*ken 9 collections meteor

通过基本的Party Meteor示例(http://meteor.com/examples/parties),

我想知道为什么你需要使用Collection.allow指定哪些插入,更新等...而不是仅仅使用Meteor.methods然后从客户端发出Meteor.call.

似乎"方法"方式总是更好,因为它更灵活(即自定义函数)

zor*_*lak 8

allow和deny接口足够灵活,可以满足您的大多数访问控制.如果您可以使用内置函数,那么最终会得到更清晰,更易理解,更易读的代码.它也更像Meteoric,因为它保留了Meteor的"数据库无处不在"的抽象,即能够直接在客户端上执行数据库操作.

可以拒绝集合上的所有操作,然后仅通过方法公开对集合的访问.但是你最终还是有可能最终重新实现CRUD接口,并且你可能最终会重新实现allow和deny函数.

我尝试只使用Meteor.methods,如果我发现很难通过allow和deny接口来表达我需要的访问控制.例如,有时您需要一次更新两个相关集合,并且验证需要在确定操作是否应继续之前检查对两个集合的建议更改.使用Meteor.method更干净.


mac*_*our 0

您误解了 Collection.allow 的目的:它用于限制客户端代码可以对您的集合执行哪些操作。这些限制不适用于服务器端。您确实应该在 Meteor.methods 中对集合执行写入操作,然后从客户端代码调用它们。

Collection.allow 的作用是防止最终用户和潜在的黑客利用您的数据做任何符合他口味的事情。永远不要忘记您的客户端代码是可以修改的。

在您提到的示例中,假设您的派对结构中有另一个字段。您可能不希望我能够更新此字段。如果没有各方中字段名称的“更新”回调测试,我将能够在该字段中注入更改。

明白这点?