Meteor的Deny/Allow回调从何处接收其参数内容？

我再次翻阅这本显微镜手册，试图找出Allow和Deny回调从何处获取参数

collections文件夹中的posts.js：

Posts = new Meteor.Collection('posts');

Posts.allow({
    update: ownsDocument,
    remove: ownsDocument
});

Posts.deny({
    update: function(userId, post, fieldNames){
        return (_.without(fieldNames, 'url', 'title').length > 0);
    }
});

lib文件夹中的permissions.js

ownsDocument = function(userId, doc){
    return doc && doc.userId === userId;
}

假设用户调用

Posts.update("postID234232", {objectTo: insert}, function(){//callback} );

然后运行Posts.allow和Posts.deny

ownsDocument函数从何处获取userId和doc参数的内容

Posts.deny中的更新键从何处获取用户名、post和字段名的内容

1 ownsDocument函数从何处获取用户ID的内容 和文档参数来自

用户ID通过meteor.userId在客户端和服务器上的meteor中全局可用，因此当前连接的用户要在集合上执行CRUD操作，则会调用ownsDocument。传递此参数是为了方便，因为在允许/拒绝回调中，可以使用Meteor.userId访问当前用户

doc参数是受insert/update/remove影响的文档，您必须记住，允许/拒绝回调规则是在collection CRUD操作中执行的，因此我们可以访问客户端试图修改的实际文档

2 Posts.deny中的update键从何处获取 来自的用户名、帖子和字段名

当客户端调用Collection.update时，会传递一个称为mongo修饰符的对象，该对象允许您指定要修改集合中的哪些字段。 fieldNames参数包含客户端愿意修改的顶级字段名称，以此更新调用为例：

Posts.update(postId,{
  $set:{
    title:"New title !"
  }
});

update方法将标题提取为客户端想要修改的顶级字段，并将其传递给允许/拒绝规则

下面是Meteor.Collection的更新方法可以用来计算传递给allow/deny规则的参数的伪代码，这不是实际的Meteor代码，只是作为解释提供的

Meteor.Collection.prototype.update = function(selector, modifier, ...){
  // get a cursor of documents that should be impacted by the update
  var impactedDocuments = this.find(selector);
  // extract top-level fields names from the modifer [1]
  var fieldNames = _.keys(modifier.$set);
  // iterate over impacted documents
  impactedDocuments.forEach(function(impactedDocument){
    // iterate over "validators" (Meteor internal name for allow/deny rules)
    _.each(this._validators.update.allow, function(updateAllowRule){
      // call the allow rule with computed parameters
      updateAllowRule(Meteor.userId(), impactedDocument, fieldNames);
    });
  });
}

通过定义允许规则时

Collection.allow({
  update:function(userId, doc, fieldNames, modifier){
    // ...
  }
});

Meteor将此函数附加到集合中。_validators.allow.update

---

[1]

好的，所以在读了一些之后，Meteor似乎会自动将userId和doc参数传递给分配给更新的任何函数对象，并删除传递给allow或deny的键

因此，我认为一个非常重要的收获：

“userId”和“doc”必须按此特定顺序排列。我可以将自己的文档重新写入以下内容：

ownsDocument = function(theCurrentUsersId, document){
    return document && document.theCurrentUsersId === theCurrentUsersId;
}

但是用户的ID必须在文档之前

我做不到：

ownsDocument = function(document, theCurrentUsersId){
    return document && document.theCurrentUsersId === theCurrentUsersId;
}

---

可能是重复的啊，看起来不错-谢谢！令人惊叹的由updateAllowRuleMeteor.userId、impactedDocument、FieldName调用的函数；updateAllowRule不调用任何函数，它是可以传递给Collection.allowI的回调函数之一，表示行updateAllowRuleMeteor.userId、impactedDocument、FieldName；正在调用updateAllowRule函数。