【问题标题】:Firestore security rule works in simulator but fails in appFirestore 安全规则在模拟器中有效,但在应用程序中失败
【发布时间】:2018-06-26 12:19:59
【问题描述】:

我对此 Cloud Firestore 安全规则有疑问:

service cloud.firestore {
  match /databases/{database}/documents {
    match /stages/{stageId} {
      match /collections/{collectionId} {
        match /pois/{poiId} {
          allow read;
          allow write: if request.auth != null || 
            request.method == "update" && 
            request.resource.data.keys() == ["pm"];
          }

        }

    }    
  }
}

在代码中,我尝试将现有文档的字段pm 更新为具有值字典的未经身份验证的用户。 Firestore 日志显示此请求:

2018-06-26 12:46:05.476997+0100 app[59292:3472939] 5.3.0 - [Firebase/Firestore][I-FST000001] FSTWriteStream 60c000107230 mutation request: <GCFSWriteRequest 0x60c0006e9e00>: {
    writes {
      update {
        name: "projects/myApp/databases/(default)/documents/stages/dev/collections/ETzbIXBn0Z5FOsCHtHlv/pois/zJELKLTWupuMkYQNb9gl"
        fields {
          key: "pm"
          value {
            map_value {
              fields {
                key: "subLocality"
                value {
                  string_value: "Albufeira"
                }
              }
              fields {
                key: "locality"
                value {
                  string_value: "Albufeira"
                }
              }
              fields {
                key: "country"
                value {
                  string_value: "Portugal"
                }
              }
              fields {
                key: "postalCode"
                value {
                  string_value: "8200-142"
                }
              }
              fields {
                key: "adminArea"
                value {
                  string_value: "Faro"
                }
              }
              fields {
                key: "timezone"
                value {
                  string_value: "Europe/Lisbon"
                }
              }
              fields {
                key: "thoroughfare"
                value {
                  string_value: "Rua Primeiro de Dezembro"
                }
              }
              fields {
                key: "name"
                value {
                  string_value: "Rua Primeiro de Dezembro"
                }
              }
              fields {
                key: "isoCountryCode"
                value {
                  string_value: "PT"
                }
              }
            }
          }
        }
      }
      update_mask {
        field_paths: "pm"
      }
      current_document {
        exists: true
      }
    }
    stream_token: "\031\020hB\002\201\364\265\265"
}

此请求因“权限缺失或不足”而失败。

当我用这个模拟数据模拟updatestages/dev/collections/ETzbIXBn0Z5FOsCHtHlv/pois/zJELKLTWupuMkYQNb9gl

{"__name__":"/databases/(default)/documents/stages/dev/collections/ETzbIXBn0Z5FOsCHtHlv/pois/zJELKLTWupuMkYQNb9gl","data":{"pm":{"adminArea":"Germany","testArea":"Munich"}}}

模拟器允许更新。

在我的代码(Swift 项目/iOS)中,我在现有文档引用上使用 updateData 方法。

作为参数,我传递了这个数组:

["pm": ["adminArea": "Faro", "name": "Rua Primeiro de Dezembro", "postalCode": "8200-142", "locality": "Albufeira", "subLocality": "Albufeira", "isoCountryCode": "PT", "timezone": "Europe/Lisbon", "thoroughfare": "Rua Primeiro de Dezembro", "country": "Portugal"]]

知道我做错了什么吗?谢谢!

【问题讨论】:

  • @AndréKool 我不需要这样做,因为之后有一个 OR 语句。这个想法是允许经过身份验证的用户或只想更新密钥“pm”的未经身份验证的用户进行写入。安全规则模拟器还允许未经身份验证的用户访问,所以这不是这里的问题。但是感谢您调查问题!
  • 糟糕,还以为是 AND。我的错。
  • 我从未使用过firestore,但是否可以更深入地编写一个级别?因此,不要将 [pm:data] 写入位置,而是将数据写入 location/pm(希望您理解这一点)
  • @AndréKool 通常是的,但在这种情况下不是,因为 pm 不是集合而是地图。

标签: ios swift google-cloud-firestore firebase-security


【解决方案1】:

事实证明

request.resource.data.keys() == ["pm"];

在部署时没有按预期工作(即使它在模拟器中工作)。

替换为

request.writeFields.size() == 1 && "pm" in request.writeFields;

为我做了诀窍。

模拟规则是朝着可用产品迈出的一大步(Hello Google:调试规则???),但前提是它们在模拟器中的工作方式与在实时部署中的工作方式相同......

【讨论】:

    【解决方案2】:

    你可以重写这个

    request.resource.data.keys() == ["pm"];
    

    request.writeFields == ["pm"];
    

    【讨论】:

      猜你喜欢
      • 2018-03-17
      • 2021-09-13
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-06-18
      • 1970-01-01
      • 1970-01-01
      • 2011-06-17
      相关资源
      最近更新 更多