内部验证（）似乎遵守外部验证（）规则

在我们的应用程序中，我们使用Firebase的自定义登录功能在用户的验证令牌中存储一些元数据。内部验证（）似乎遵守外部验证（）规则

稍后我们将此令牌发送到我们的Web应用程序之一，以代表用户使用新的令牌执行任务以禁用安全规则。这个想法是，一个特定的位置不能被直接由认证用户写入，但是在完成一些服务器端计算和验证之后，可以在该位置写入数据。

这里是我想要做的一个示例代码：

var testRef = new Firebase(firebaseApp + 'test'); 
testRef.auth(userFirebaseAuthToken, function(error, result) { 
    if (!error) { 
     var userId = result.auth.userId; 
     // perform validations and calculations 
     var tokenGenerator = new FirebaseTokenGenerator(firebaseSecret); 
     var token = tokenGenerator.createToken({admin: true}); 
     var protectedRef = new Firebase(firebaseApp + '/protected/'); 
     protectedRef.auth(token, function(error) { 
      if (!error) { 
       protectedRef.child('foo').push({id: userId}); 
      } 
     }); 
    } 
});

但我得到这个错误：

FIREBASE WARNING: set at /protected/foo/-Ityb1F6_G9ZrGCvMtX- failed: permission_denied

当期望的行为是能够在写使用令牌的位置使用admin令牌。

我知道这可能不是Firebase问题，但是一些JavaScript好/坏的部分，但我需要做的是代表用户写一些受保护的位置，即使它没有被授权写入该位置，但需要进行身份验证。

来源

2013-05-07 racetrack

根据我从我的测试单位和经验中看到的情况，我不认为new Firebase实际上给了你一个独立的数据连接。也就是说，这些都连接到同一火力地堡实例内部（我认为）：

var refA = new Firebase('...'); 
var refB = new Firebase('...');

所以，如果你想重新授权，我敢肯定，你需要调用unauth第一，这将可能也会影响您的testRef实例。

如果您确实需要同时使用不同身份验证向数据库打开多个实例，那么您必须查看node-fibers或其他一些工作池模型，这将允许单独的连接。

但是，请多加考虑一下;你可能会推翻你的方法。如果您正在代表没有权限的用户编写代码，那么您可能实际上不需要以该用户身份进行身份验证。

我已经编写了一个完整的应用程序，其中包含由第三方应用程序使用的安全Firebase组件，然后写回特权路径，然后由用户读取，并且尚未遇到服务器将需要降级其权限来执行此操作。

这并不意味着假定我知道你的用例，只是为了给你一些鼓励让事情变得简单，因为尝试认证并不简单。

我的方法是将Firebase安全规则视为最后一道防线 - 就像我的防火墙 - 而不是特权进程所使用的编程算法的一部分。

来源

2013-05-07 15:31:44 Kato

这是正确的，Firebase连接受域限制。第一次验证时，对该域的所有后续引用都会继承该状态，直到您调用unauth为止。同样，如果您使用不同域调用“新Firebase（）”两次，那些引用将是独立的，不会共享认证状态。 – Anant 2013-05-07 18:16:31

内部验证（）似乎遵守外部验证（）规则

回答

相关问题