如何在没有身份验证的情况下添加 firebase 数据库规则? [英] How to add firebase database rules without authentication?

问题描述

我想添加 Firebase 实时数据库规则，它设置为默认值，但我无法使用身份验证，因为我的应用程序已经部署了数据库中的数据.

i want add Firebase Real-time database rules it is set to default and i cant use authentication because my app is already deployed with data in database.

请帮忙，谢谢

推荐答案

要授予任何用户对您的实时数据库 (RTDB) 的完全读/写访问权限，您可以使用以下全局读/写访问规则:

To grant any user complete read/write access to your Realtime Database (RTDB), you can use these global read/write access rules:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

这些规则将允许任何人读取、写入、删除或更改您数据库中的数据 - 包括删除整个数据库.这些规则还会触发来自 Firebase 的定期电子邮件，警告您您的规则不安全.

These rules will allow anyone to read, write, delete or change the data in your database - including deleting the entire database. These rules will also trigger periodic emails from Firebase warning you that your rules are insecure.

除了使用如此广泛的规则外，您还可以通过多种方式收紧数据库以防止此类滥用.

Instead of using such wide-reaching rules, there are a number of ways you can tighten up your database to prevent such abuse.

Firebase 安全规则记录在此处，它们的API 参考在这里，您可以在此处管理它们.

Firebase Security Rules are documented here, their API reference is here and you can manage them here.

因为您已经表明您不打算使用 Firebase 身份验证，所以我将省略这些示例，而是让您参阅这些示例的文档.由于您尚未提供任何存储在数据库中的数据示例，因此我还将提供有关将汽车存储在数据库中的各种示例.

Because you have indicated that you aren't planning to use Firebase Authentication, I will omit those examples and instead refer you to the documentation for those examples. As you haven't provided any examples of data stored in your database, I will also be coming up with various examples around storing cars in a database.

假设您的应用在 /cars 下包含一个可公开访问的汽车数据库，其形状如下:

Let's say your app contains a publicly accessible database of cars under /cars with the following shape:

interface Car {
  make: string,
  model: string,
  year: number,
  type: string
}

我们可以不使用上面完全公开的规则，而是让用户只能读/写/cars节点:

Instead of using the completely public rules above, we can instead make it so users can only read/write to the /cars node:

{
  "rules": {
    "cars": {
      ".read": true,
      ".write": true
    }
  }
}

根据上述规则，您可以创建、更新、删除/cars 下的任何节点，但对/trains 的读/写将被拒绝.这是因为除非另有定义，否则安全规则默认为 false(拒绝).如果安全规则会抛出错误(语法错误、丢失数据、错误的对象类型)，则将其视为 false(拒绝).

With the above rules, you can create, update, delete any node under /cars, but a read/write to /trains would be denied. This is because security rules default to false (deny) unless defined otherwise. If a security rule would throw an error (syntax error, missing data, bad object type), it is treated as false (deny).

根据上述规则，任何用户都可以创建 /cars/someId/path 并用大量无关数据填充它.

With the above rules, any user could create /cars/someId/path and fill it with heaps of irrelevant data.

为了解决这个问题，我们可以定义一个动态节点路径下的节点(例如cars/$carId)并选择哪些字段将被读取/写入:

To correct this, we can define the nodes under a dynamic node path (such as cars/$carId) and choose what fields will be read/writable:

{
  "rules": {
    "cars": {
      // any car is readable
      ".read": true,

      "$carId": {
        "make":  { ".write": true },
        "model": { ".write": true },
        "year":  { ".write": true },
        "type":  { ".write": true }
      }
    }
  }
}

使用这些规则，您现在可以在数据库中创建和存储 Car 对象.您将无法将数据添加到 /cars/someId/path 等位置，但您仍然可以像以前一样将数据添加到 /cars/someId/make/path.

Using these rules, you can now create and store a Car object in your database. You won't be able to add data to locations like /cars/someId/path but you can still add data to /cars/someId/make/path like before.

这就是数据验证规则的用武之地.我们可以确保节点的类型是我们期望的(只要它是数字、字符串或布尔值):

This is where data validation rules come in. We can ensure that the type of a node is what we expect (as long as it's a number, string or boolean):

{
  "rules": {
    "cars": {
      // any car is readable
      ".read": true,

      "$carId": {
        "make":  { ".write": true, ".validate": "newData.isString()" },
        "model": { ".write": true, ".validate": "newData.isString()" },
        "year":  { ".write": true, ".validate": "newData.isNumber()" },
        "type":  { ".write": true, ".validate": "newData.isString()" }
      }
    }
  }
}

上述规则强制Car 对象的每个部分的类型，但它们不确保整个Car 对象都存在.为了对节点的子节点执行验证，例如确保整个汽车对象都存在，我们将 ".validate" 规则上移一级:

The above rules enforce the types of each part of a Car object, but they don't make sure the entire Car object is present. To enforce validation on the children of a node, such as making sure the entire car object is present, we move the ".validate" rule up one level:

{
  "rules": {
    "cars": {
      // any car is readable
      ".read": true,

      "$carId": {
        // a car object must be complete
        ".validate": "newData.child('make').isString() && newData.child('model').isString() && newData.child('year').isNumber() && newData.child('type').isString()",

        "make":  { ".write": true },
        "model": { ".write": true },
        "year":  { ".write": true },
        "type":  { ".write": true }
      }
    }
  }
}

根据上述规则，您现在可以创建/更新/删除存储在 /cars 下的任何汽车，只要它们看起来像一个 Car 对象.

With the above rules, you can now create/update/delete any cars stored under /cars as long as they look like a Car object.

简单地允许完全写入访问可能不是您想要的.通过调整 ".write": "true"，我们可以对允许更改的数据应用额外的限制.

Simply allowing complete write access may not be what you desire. By tweaking ".write": "true", we can apply additional restrictions on what data is allowed to be changed.

如果我们想让你只能创建/更新汽车，但不能删除它，我们可以使用:

If we wanted to make it so you can only create/update a car, but not delete it, we can use:

".write": "newData.exists()"

如果我们想让你只能创建一辆车，但不能更新/删除它，我们可以使用:

If we wanted to make it so you can only create a car, but not update/delete it, we can use:

".write": "!data.exists()"

如果我们想让你只能更新现有的汽车，而不能创建/删除它，我们可以使用:

If we wanted to make it so you can only update an existing car, but not create/delete it, we can use:

".write": "data.exists() && newData.exists()"

---

使用这些构建块，您现在应该能够在不阻塞现有应用程序的情况下收紧数据库.

---

Using these building blocks, you should now be able to tighten your database without blocking your existing application.

这篇关于如何在没有身份验证的情况下添加 firebase 数据库规则?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！