Parse Server Node.js SDK：Parse.User.become的替代方案是什么？

Question

我希望完全将我的客户端应用与Parse服务器分离，以便将来更容易切换到其他Baas/自定义后端。因此，所有客户端请求都将指向一个node.js服务器，该服务器将代表用户向Parse发出请求。

Client <--> Node.js Server <--> Parse Server

因此，我需要node.js服务器能够在不同用户之间切换，以便我可以保持他们的身份验证环境。

我知道如何验证身份，然后保留用户的sessionToken，并且在我的研究中发现，“接受”的解决方案是调用Parse.User.disableUnsafeCurrentUser，然后使用Parse.User.become()来将当前用户切换为进行请求的用户。

但这感觉像是一种hackish方法，我很确定它迟早会导致竞争条件，即在向Parse发送请求之前切换了当前用户。

我发现的另一个解决方案是不关心Parse.User，而是使用masterKey在服务器上保存所有内容，但这将使服务器负责ACL。

除了这两个解决方案，有没有其他方法可以代表不同的用户进行请求？

- DrakaSAN

Answer 1

任何对后端的请求（例如 query.find()，object.save() 等）都可以在最后一个参数中添加可选的 options 参数。这使您可以指定额外的权限级别，例如强制使用主控密钥或使用特定会话令牌。

如果您拥有会话令牌，则您的服务器代码可以代表该用户发出请求，保留 ACL 权限。

假设您有一个 Item 对象的表格，并且我们依靠 ACL 来确保用户只能检索自己的项目。以下代码将使用显式会话令牌，并仅返回用户可以查看的项目：

// fetch items visible to the user associate with `token`
fetchItems(token) {
  new Parse.Query('Item')
    .find({ sessionToken: token })
    .then((results) => {
      // do something with the items
    });
}

become()最初是为Parse Cloud Code环境设计的，每个请求都存在于一个沙盒中，并且您可以依赖于每个请求的全局当前用户。在Node.js应用程序中使用它并没有太多意义，因此我们可能会废弃它。

- Andrew I

Answer 2

我最近编写了一个NodeJS应用程序并遇到了同样的问题。 我发现Parse.User.disableUnsafeCurrentUser和Parse.User.become（）的组合不仅是 hackish，而且还引起了其他几个我无法预料的问题。 因此，这就是我所做的：我使用Parse.Cloud.useMasterKey();，然后像加载常规用户对象一样通过会话ID加载当前用户。 它看起来有点像：

module.exports = function(req, res, next) {
  var Parse = req.app.locals.parse, query;
  res.locals.parse = Parse;
  if (req.session.userid === undefined) {
    res.locals.user = undefined;
    return next();
  }
  Parse.Cloud.useMasterKey();
  query = new Parse.Query(Parse.User); 
  query.equalTo("objectId", req.session.userid);
  query.first().then(function(result) {
    res.locals.user = result;
    return next();
  }, function(err) {
    res.locals.user = undefined;
    console.error("error recovering user " + req.session.userid);
    return next();
  });

};

这段代码显然可以进行优化，但你可以看到其一般思路。优点：它能够工作！缺点：不再使用Parse.User.current()，并且需要在后端特别注意，确保没有条件会导致未经许可的数据被覆盖。

- Philipp

---

所以你正在使用我找到的第二个解决方案。我很感激有人确认它有效，但如果可能的话，我更愿意不在服务器上进行权限检查。 - DrakaSAN

哎呀——我在你的问题中漏掉了那一段话，关于第二个解决方案。抱歉！是的，缺少ACL强制执行很烦人，这意味着你必须显式地检查每个用户是否被允许读取或写入。 - Philipp