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

Posted 2023-03-16

【中文标题】Parse Server Node.js SDK：Parse.User.become 的替代方案？

【英文标题】：Parse Server Node.js SDK: Alternative to Parse.User.become?

【发布时间】：2016-06-22 08:59:43

【问题描述】：

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

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

因此，我需要 node.js 服务器能够在用户之间切换，以便我可以保留他们的身份验证上下文。

我知道如何进行身份验证，然后保留用户的 sessionToken，我在研究过程中看到这个问题的“接受”解决方案是调用Parse.User.disableUnsafeCurrentUser，然后使用Parse.User.become() 切换当前用户给提出请求的人。

但这让人感觉很骇人听闻，而且我很确定它迟早会导致在向 Parse 发出请求之前切换当前用户的竞争条件。

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

有没有办法向这两个以外的不同用户提出请求？

【参考方案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 应用程序中实际上没有意义，我们可能会弃用它。

【参考方案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()，并且需要在后端特别注意不要出现有人未经许可覆盖数据的情况。

【讨论】：

所以您使用的是我找到的第二种解决方案。我很感激有人确认它可以工作，但如果可能的话，我宁愿不必在服务器上进行权限检查。

哎呀-我有点错过了您关于第二个解决方案的问题中的那一段。对不起！是的，没有 ACL 强制执行很烦人，这实质上意味着您必须明确检查每个用户是否被允许读取或写入。