流星中minimongo的原因是什么

Question

什么是实际原因以及在流星中应该如何使用 minimongo？为了安全起见，客户端不应访问查询。所以它们应该只保存在服务器上。因此，无论如何都不应该在客户端上查询任何内容。

即使查询代码保留在客户端，服务器上的数据也不应该由客户端直接更新，而是应该将执行的操作发送到服务器，服务器应该联系 Mongo 并执行操作。我是否正确理解了这部分？这是允许/拒绝规则的原因吗？

但是，meteor 文档仍然认为允许/拒绝规则不够安全，并且仍然不应允许此类写入。我是否正确理解了第二部分？

如果是这样，那么使用 minimongo 的原因是什么？只是为了原型设计吗？如果我想获得最高的安全性并因此避免使用允许/拒绝（禁止一切），那么我可以删除 minimongo，还是它是必需的并且仍然用于某些事情？为了什么？

谢谢。

Answer 1

由于以下内容对于评论来说太短了，我将创建它作为答案。我不会声称它是完整的。希望它能很好地解释这种情况。

最初 minimongo 旨在反映对集合的操作“就好像它们会出现在服务器端一样”。 Meteor 自动将执行的操作与服务器端集合同步 - 为您节省大量设计和开发时间。

允许/拒绝被发明为一个额外的控制层，因此客户端只能操作涉及允许/拒绝中定义的操作的数据。

然而，a critical security vulnerability 已被发现，这就是为什么现在不鼓励这样做，而应使用服务器端方法。

您可以自己尝试，方法是创建一个集合并将allow 设置为true 以将insert, update, delete 设置为true，然后在客户端上执行其中的一些操作。一个简洁的功能，但不幸的是已经过时了（甚至不确定是否 100% 在新版本中工作）。

但这还不是全部！当涉及到cursors 的客户端查询操作时，您仍然可以使用minimongo。非常强大的概念包括cursor.observe 和cursor.observeChanges。如果对数组使用传统的迭代方法，您还可以创建需要大量工作的复杂查询。

最后 minimogno 仍然是您同步文档的目的地（由客户端订阅并由服务器发布）。它表示数据的投影，可以在publication 中定义为最精细的数据。