【问题标题】:How to share data between users in Firebase?如何在 Firebase 中的用户之间共享数据?
【发布时间】:2019-07-20 01:52:51
【问题描述】:

在这样的数据库中:

{
  "users": {
    "simplelogin:213": {    
      "provider": "password",
      "name": "bobtony",
      "friends": {
        "Andrew Lee": true,
        "James Tamplin": true
      }   
    },
    "twitter:123": {
      "provider": "twitter",
      "name": "Andrew Lee",
      "friends": {}
    },  
    "facebook:456": {
      "provider": "facebook",
      "name": "James Tamplin",
      "friends": {}
    }   
  },  
  "messages": {  
    "simplelogin:213": {    
       "-JkpwAnieKjQVsdtPD4m" : {
          "content" : "Hello World"
      }
    }  
  }  
}

考虑到 bobtony 将 Andrew Lee 添加为他的朋友,Andrew Lee 如何阅读 bobtony 消息?一个类似的问题问here,但没有好的解决方案。我知道我可以有一个规则来允许阅读消息,但是“朋友”用户只是不知道阅读它们的路径。

更新:经过一段时间的思考,我得到了:

{
  "users": {
    "user1": {  
      "name": "bobtony",
      "partners": {
        "user2": {
            "accepted": true
        }
      },
      "customers":{
        "customer1": true,
        "customer2": true
        // hundreds of clients
      },
      "orders":{
        "order1": true,
        "order2": true
        // hundreds of orders
      }     
    }
  },  
  "customers": {  
    "customer1": {  
       "name" : "james"
      }
    }
}

那么,有这样的东西可以吗?这样我就可以遍历自己的客户和合作伙伴的客户。

【问题讨论】:

    标签: firebase firebase-security


    【解决方案1】:

    如果您这样设置数据:

    {
      "users": {
        "simplelogin:213": {    
          "provider": "password",
          "name": "bobtony",
          "friends": {
            "twitter:123": "Andrew Lee",
            "facebook:456": "James Tamplin"
          },
          "messages": {
            "sent" : {
              "-JkpwAnieKjQVsdtPD4m" : {
                "content" : "Hello World",
                "uid" : "twitter:123"
              }
            }
          }
        },
        "twitter:123": {
          "provider": "twitter",
          "name": "Andrew Lee",
          "friends": {
            "simplelogin:213": "bobtony"
          },
          "messages": {
            "received" : {
              "-JkpwAnieKjQVsdtPD4m" : {
                "content" : "Hello World",
                "uid" : "simplelogin:213"
              }
            }
          }
        },  
        "facebook:456": {
          "provider": "facebook",
          "name": "James Tamplin",
          "friends": {
            "simplelogin:213": "bobtony"
          }
        }   
      }
    }
    

    如果发送用户的 uid 在接收用户的“/friends”中,您可以设置规则,以便一个用户可以写入另一个用户的/messages/received

    {
      "rules": {
        "users" : {
          "$user_id" : {
            ".read": "auth.uid === $user_id",
            ".write": "auth.uid === $user_id",
            "messages" : {
              "received" : {
                ".write" : "root.child('users').child($user_id).child('friends').hasChild(auth.uid)"
              }
            }
          }
        }
      }
    }
    

    您需要使用Firebase.transaction() 来确保只有在写入received 成功时才能成功写入sent

    【讨论】:

    • 实际上,“消息”将是“消费者”,所以我需要与其他用户共享客户列表。因此,当一个用户添加为“朋友”或“合作伙伴”时,他将与相同的客户合作。我开始认为 Firebase 不适合我的商业模式。
    • @MárcioSouzaJúnior 你对此有什么结论吗?我目前正在使用 Couchbase Server 和 Couchbase Lite 很好地解决了这个问题;但它在服务器上有点重(需要 8-16GB 实例才能使用 Sync Gateway 顺利运行),所以我想知道 Firebase 是否能更好地满足我的需求,或者至少降低服务器成本
    • @Adamski,我得出的结论是 Firebase 不适合我的需求。仍然在服务器端使用 MySQL,在客户端使用 SQLite。
    【解决方案2】:

    此视频很有帮助:https://www.youtube.com/watch?v=3hj_r_N0qMs 大体思路是一样的,而不是isTeacher == true,只是将它们添加到另一个用户的角色中(例如userX { usersWithViewAccess : userY, userZ ... }

    service cloud.firestore { 
      match /databases/{database}/documents { 
        match /class/ {classId}/grades/{studentId} {
            allow read: if request.auth.uid == studentld; 
            allow write: if get(/databases/$(database)/documents/ 
            administrators/$( request. auth.uid)).data.isTeacher == true; 
            }
        }
    }
    

    以此为规则

    administrators: { 
        userid123: { 
            isTeacher : true 
        }
        userid009: { 
            isAdminAssistant : true 
        }
    }
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-07-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多