Javascript meteor-库文件夹中的发布规则是否存在安全风险？

我正在关注一个关于流星的教程。我们将todos集合信息放在

lib/collections/todos.js

中。该应用程序是由iron生成的

当我在浏览器中加载应用程序时，我可以清楚地看到sources下的文件夹。它看起来像：

Todos = new Mongo.Collection('todos');

// if server define security rules
// server code and code inside methods are not affected by allow and deny
// these rules only apply when insert, update, and remove are called from untrusted client code

if (Meteor.isServer) {
  // first argument is id of logged in user. (null if not logged in)
  Todos.allow({
    // can do anythin if you own the document
    insert: function (userId, doc) {
      return userId === doc.userId;
    },

    update: function (userId, doc, fieldNames, modifier) {
      return userId === doc.userId;
    },

    remove: function (userId, doc) {
      return userId === doc.userId;
    }
  });

  // The deny method lets you selectively override your allow rules
  // every deny callback must return false for the database change to happen
  Todos.deny({
    insert: function (userId, doc) {
      return false;
    },

    update: function (userId, doc, fieldNames, modifier) {
      return false;
    },

    remove: function (userId, doc) {
      return false;
    }
  });
}

---

我的问题是这是否构成了安全威胁？如果javascript文件存储在

lib

目录中，它会被客户端劫持吗？

永远不要使用

Meteor.isServer

。而是将服务器方法放在

/server

下。那里的代码没有提供给客户

我不同意将插入移动到服务器比在客户机上进行插入更安全的说法。毕竟，登录用户只需打开控制台并键入Meteor.call（'addPost'，new\u post\u fields）（在检查了

postsCollection

中的文档以对模式进行反向工程后），服务器就会很高兴地执行该操作。通过方法调用进行插入的代价是丢失延迟补偿，这是Meteor的主要优点之一。您的应用程序将感觉滞后，因为您的插入都需要服务器往返来反映在UI中

让我更具体地回应Removery的评论：

如果您的方法代码位于/lib中，那么它将对客户端和服务器都可见，并且将在每个位置运行一次，并进行延迟补偿。它可以在客户端修改，但不能在服务器上修改。但这是可以看到的

如果您的方法代码位于/server中，则它将仅对服务器可见，并且将在没有延迟补偿的情况下运行

Meteor.call（）可以通过任何参数从客户端的控制台调用。您的方法代码需要防止此类攻击

---

我建议在服务器上至少使用允许/拒绝规则的组合来控制进入集合的内容。

服务器方法正是延迟补偿发挥作用的原因：调用服务器方法并立即更新UI（就像从客户端更新一样）。延迟补偿并不意味着什么，如果一切都发生在客户端上……本文准确地解释了我刚才做的事情，你没有回答OP的问题。请删除或更新您的答案…所有安全检查都应在服务器上进行。这是DDP无可争辩的事实。您引用的文章要求方法代码位于/lib中，即在客户端和服务器上，以便获得延迟补偿。这使您的服务器代码对客户端可见。即使它无法改变，但它可以被看到，这有助于人们了解如何攻击它。同意所有的安全检查都应该在服务器上进行，但希望补充一点，如果这些检查对客户端来说是不透明的，那就更好了。在我看来，你的解决方案是反模式的。