Firebase 实时数据库的这些默认安全规则是什么意思? [英] What do these default security rules for the Firebase Realtime Database mean?

问题描述

我在 Firebase 上创建了一个新项目，并在其中创建了一个实时数据库.当被问及我的数据库的安全规则时，我选择了以测试模式启动.

I've created a new project on Firebase, and created a Realtime Database in there. When asked about the security rules for my database, I selected to Start in test mode.

现在我的数据库在 Firebase 控制台中的安全规则显示为:

Now the security rules of my database in the Firebase console show up as:

{
  "rules": {
    ".read": "now < 1622790000000",  // 2021-6-4
    ".write": "now < 1622790000000",  // 2021-6-4
  }
}

这些规则是什么意思?我该如何更改它们以使其更安全?

What do these rules mean? And how can I change them to be more secure?

推荐答案

这些默认的测试模式规则是一个简单的包罗万象的规则，允许世界上的每个人在给定日期之前读取和写入您的数据库.

These default test mode rules are a simple catch-all that allows everyone in the world to read from and write to your database until a given date.

让我们分解规则，看看它们是如何工作的:

Let's break the rules down to see exactly how they work:

1. .read" 和 .write" 节点直接位于 rules" 之下，决定谁可以读取/写入整个数据库中的数据.

1. The ".read" and ".write" nodes immediately under "rules" determine who can read/write the data in the entire database.

now 变量 由 Firebase 自动设置为服务器上的当前时间.此值以 自纪元以来的毫秒数为单位，这是在 Firebase 中也存储时间戳的推荐值.

The now variable is automatically set by Firebase to be the current time on the server. This value is in milliseconds since the epoch, which is the recommended value to also store timestamps in Firebase.

规则中的 1622790000000 值是未来某个时间点的时间戳.让我们以更易读的日期格式来看看这个值是什么:

The 1622790000000 value in the rules is the timestamp of some point in the future. Let's see what this value is in a more readable date format:

   console.log(new Date(1622790000000))

  

2021-06-04T07:00:00.000Z"

"2021-06-04T07:00:00.000Z"

因此，在 2021 年 6 月 4 日之前，任何人都可以读取或写入我们数据库中的所有数据.在那之后，任何人都无法再使用客户端 SDK 访问数据.Firebase Admin SDK 完全绕过这些规则，因此它们不受影响.

So anyone can read of write all data in our database until June 4th, 2021. After that date nobody can access the data anymore with the client-side SDKs. The Firebase Admin SDKs bypass these rules altogether, so they are not affected.

您可能从 Firebase 收到了这样的消息:

You may have gotten a message like this from Firebase:

您选择在测试模式下开始开发，这使您的实时数据库实例完全对 Internet 开放.由于此选择使您的应用容易受到攻击者的攻击，因此您的数据库安全规则配置为在前 30 天后停止允许请求.在 5 天内，所有客户端对您的实时数据库实例的请求都将被拒绝.

You chose to start developing in Test Mode, which leaves your Realtime Database instance completely open to the Internet. Because this choice makes your app vulnerable to attackers, your database security rules were configured to stop allowing requests after the first 30 days. In 5 day(s), all client requests to your Realtime Database instance will be denied.

此消息表示，由于您的安全规则中的时间戳，对您数据的访问权限即将到期.

This message means that access to your data is about to expire, due to timestamp that is in your security rules.

实际上很容易将测试模式扩展到另一个截止日期.您需要做的就是更改 1622790000000 值.例如，要延长到 7 月 4 日，我可以将值设置为 1625382000000.

It's actually pretty easy to extend the test mode to another deadline. All you need to do is change that 1622790000000 value. For example, for extend it to July 4th, I can set the value to 1625382000000.

为了确定要使用的值，我运行了这个小小的 JavaScript 代码段:

To determine the value to use, I run this tiny JavaScript snippet:

   console.log(new Date("2021-07-04T07:00:00.000Z").getTime())

这是另一个用于计算这些值的工具.

Here's another tool to calculate these values.

通过使用1625382000000，我们将测试模式延长了一个月，每个人都可以读/写整个数据库，直到 2021 年 7 月 4 日.

By using 1625382000000 we've extended test mode for a month and everyone can read/write the entire database until July 4, 2021.

在某些时候，您应该想出一种更好的方法来保护您的(用户)数据，而不仅仅是在特定日期之前打开它.当我开始一个项目时，我通常会正确地做这件事，但如果你晚一点开始也没关系.

At some point you should come up with a better way to protect your (user's) data than just opening it until a specific date. I typically do this right when I start a project, but it's also fine if you start it a bit later.

重要的是，您应该将服务器端安全规则与您应用的客户端源代码一视同仁.

我同时开发我的代码和规则.所以:

I develop my code and rules in tandem. So:

1. 我从一个完全封闭的数据库开始，因为还没有需要访问任何数据的代码.

1. I start with a fully closed off database, since there is no code yet that needs access to any data.

我手动添加了一些数据到数据库中，并编写代码来读取它.在这一点上，我编写了只允许对特定数据进行读访问的安全规则.所以它可能是 ".read": true，但它在我的 JSON 结构中会更深.即使是这样简单的规则也已经可以阻止许多坏人.

I add some data manually to the database, and write code to read it. At this point, I write security rules that only allow read-access to that specific data. So it may be ".read": true, but it'll be much deeper in my JSON structure. Even such simple rules will already block many bad actors.

我第一次希望应用程序写入到数据库也是在我添加身份验证时.通常我从匿名身份验证开始，因为它不需要我输入任何凭据.

The first time I want the app to write to the database is also when I add authentication. Typically I start with anonymous auth, since it does not require me to enter any credentials.

然后我将硬编码的 UID 包含在我的安全规则中，以确保只有我可以写入数据.在我添加适当的数据所有权之后，您仍然经常会在我的规则中发现这个顶级 ".write":"auth.uid === 'hardcodedUidOfPufsAnonymousUser'".

I then include the hard-coded UID in my security rules, to ensure only I can write data. You'll often still find this top-level ".write": "auth.uid === 'hardcodedUidOfPufsAnonymousUser'" in my rules much later, after I added proper data ownership.

使用 Firestore 时，我有时会按照此处的说明进行改进:对管理员和普通用户使用相同身份验证方法时的用户冲突 |Firebase 身份验证

When using Firestore I sometimes evolve that as explained here: User conflict when using same Auth method for Admin and Normal users | Firebase Auth

在我添加(通常是列表)数据的任何时候，我都会考虑谁拥有"这些数据，谁能读懂.然后我扩展我的规则以允许该访问，仅此而已.

At any point when I add (typically lists of) data, I think through who "owns" this data, and who can read it. I then expand my rules to allow exactly that access, and nothing more.

在我编写代码时需要更新我的安全规则会减慢我的编码速度，但无论如何我都会很乐意这样做.在每一步都确保我数据库中的数据安全，让我可以让人们放心地访问应用程序/数据库.我建议你也这样做.

This need to update my security rules as I write code slows down the pace at which I code, but I'll gladly do it anyway. Keeping the data in my database secure at every step, allows me to give people access to the app/database with confidence. I recommend you do the same.

有关更多信息，我建议阅读:

For more information, I recommend reading:

• 有关安全规则的 Firebase 文档，其中包含这些常见用例的示例:
• 仅限内容所有者访问
• 公共读取、私有写入访问
• 基于属性和角色的访问
• 所有经过身份验证的用户都可以读/写所有数据

• The Firebase documentation on security rules, which contains examples of these common use-cases:
• Content-owner only access
• Public read, private write access
• Attribute and role based access
• All authenticated users can read/write all datsa

这篇关于Firebase 实时数据库的这些默认安全规则是什么意思?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！