真正的原因是什么？在流星中应该使用minimongo吗？为了安全起见，客户端不应有权访问查询。因此，它们应仅保留在服务器上。因此，无论如何都不应该在客户端上查询任何东西。
即使将查询代码保留在客户端上，客户端也不应该直接更新服务器上的数据，而是应将已执行的操作发送到服务器，并且服务器应与Mongo联系并执行操作。我对这部分理解正确吗？这是允许/拒绝规则的原因吗？
但是，流星文档仍然认为允许/拒绝规则不够安全，因此人们仍然不应允许这样的写操作。我能正确理解第二部分吗？
如果是，那么使用minimongo的原因是什么？只是为了原型吗？如果我想获得最高的安全性并因此避免使用allow / deny（禁止所有操作），那么我可以删除minimongo，还是需要它并且仍用于某些用途？为了什么？
谢谢。
答案 0 :(得分：2)
由于以下内容对评论太短，因此我将其创建为答案。我不会声称它是完整的。希望它能很好地解释这种情况。
最初 minimongo旨在反映对集合的操作“就像它们将出现在服务器端一样”。 Meteor会自动将执行的操作与服务器端集合同步-在设计和开发方面为您节省了大量时间。
允许/拒绝是作为额外的控制层而发明的，因此客户端只能操纵涉及允许/拒绝中定义的操作的数据。
但是，发现a critical security vulnerability，这是为什么现在不建议这样做，而应该使用服务器端方法的原因。
您可以自己尝试，方法是创建一个集合并将allow的{{1}}设置为true，然后在客户端上执行其中的一些操作。一项简洁的功能，但不幸的是已过时（甚至不确定100％是否在较新版本中可用）。
但这还不是全部！在涉及cursors的客户端上进行查询操作时，仍然可以使用insert, update, delete。非常强大的概念包括cursor.observe和cursor.observeChanges。如果对数组使用传统的迭代方法，您还可以创建复杂的查询，而这将需要大量的精力。
最后 minimongo仍然是同步文档（由客户端订阅并由服务器发布）的目标。它表示数据的投影，可以在publication内定义最详细的数据。