Firestore安全规则中的递归通配符未按预期工作 [英] Recursive wildcards in Firestore security rules not working as expected

查看:57
本文介绍了Firestore安全规则中的递归通配符未按预期工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个像这样的数据结构(当然是 Collections Documents 而不是 JSON ,但是你知道了)

I have a data structure like this (Collections and Documents rather than JSON of course but you get the idea):

{
   users: {
      user1:{
         name: Alice,
         groups: {
            groupA:{subbed:true},
            groupB:{subbed:true}
         }
      },
      user2:{
         name: Bob,
         groups: {
            groupC:{subbed:true},
            groupD:{subbed:true}
         }
      }
   }
}

基本上,这是注册用户ID和每个用户订阅的组ID.我想编写一条安全规则,仅在用户配置文件和子集合为当前身份验证用户时才允许访问它们,并且根据我对文档的阅读,我认为通配符可以实现此目的...

Basically this is registered users IDs and the group IDs that each user is subscribed to. I wanted to write a security rule allowing access to a users profile and sub-collections only if they are the current auth user and, based on my reading of the docs, I thought that a wildcard would achieve this...

match /users/{user=**}{
   allow read,write: if user == request.auth.uid;
}

有了这个,我可以很好地阅读user文档,但是当我尝试读取groups子集合时出现权限错误.我只能通过明确匹配子集合来使其工作...

With this in place I can read the user document fine but I get a permissions error when I try and read the groups sub-collection. I can only make it work by matching the sub-collection explicitly...

match /appUsers/{user}{
   allow read,write: if user == request.auth.uid;

   match /groups/{group}{
      allow read,write: if user == request.auth.uid;
   }
}

...所以我的问题是,两个示例之间有什么区别?我对递归通配符有什么误解?我认为第一个示例的{user=**}部分应授予对user文档及其所有子集合,子子集合等的访问权限(对于授权用户),并且应无限制(对于授权用户),并且应删除编写的需要在第二个示例中必须做的专门针对存储数据的规则.

...so my question is, what is the difference between the two examples and what am I misunderstanding about the recursive wildcards? I thought that the {user=**} part of the first example should grant access to the user document and all its sub-collections, sub-sub-collections etc etc ad infinitum (for the authorised user) and should remove the need to write rules specifically for data stored lower down as I have had to do in the second example.

我只是在很短的时间里与Firestore闲逛,所以这可能是一个愚蠢的问题:)

I've only been messing around with Firestore for a short time so this could be a real dumb question :)

谢谢

推荐答案

firebase文档有点令人困惑.在测试中发现,我需要设置两个规则来授予用户写入用户文档和所有子集合(及其子文档)的权限,这是管理用户数据的最合逻辑的设置.

The firebase docs are a bit confusing when it comes to using the recursive while card. What I found in testing was that I needed to set two rules to give a user permission to write to the users document and all sub collections (and their sub documents) which is the most logical setup for managing user data.

您必须设置两个规则.

  1. 授予用户对/users/{userId} 文档的权限
  2. 授予所有从/users/{userId} 路径开始的子集合及其子文档的用户权限.

  1. Give user permission to the /users/{userId} document
  2. Give user permission to all sub collections and their sub documents that begin at the /users/{userId} path.

service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { allow read, write: if request.auth.uid == userId; } match /users/{userId}/{document=**} { allow read, write: if request.auth.uid == userId; } } }

service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { allow read, write: if request.auth.uid == userId; } match /users/{userId}/{document=**} { allow read, write: if request.auth.uid == userId; } } }

规则

很抱歉包含这些图像.我无法正确格式化它们.

Sorry about including the images. I couldn't get SO to format them correctly.

这篇关于Firestore安全规则中的递归通配符未按预期工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆