在Firebase和代码中编写规则 [英] Writing Rules both in Firebase and in your Code

问题描述

Firebase建议，除了代码中包含的规则(swift/java等)外，我们还可以在其Firebase规则部分的控制台(数据库/存储)上在线编写安全规则.为什么是这样?我觉得这会重复吗?

Firebase suggests we write security rules in both our firebase rules section online at their console for (database/storage) in addition to the rules that we have in our code (swift/java, etc). Why is this? I feel like this would be repetitive?

推荐答案

这在客户端-服务器体系结构中非常常见.

This is very common in a client-server architecture.

• 服务器必须验证数据，以确保不会将任何无效/损坏的数据写入数据库.

• The server must validate the data to ensure that no invalid/corrupt data every gets written to the database.

客户端应验证数据以为用户提供最佳体验.

The client should validate the data to give the user the best experience.

这里有个例子:假设您有一个旅行网站，用户可以在其中选择旅程的开始和结束日期.常见的验证是结束日期不能早于开始日期.在Firebase数据库安全规则中，这可能是:

Think of an example here: say that you have a travel site where the user selects the start and end date of their journey. A common validation will be that the end date cannot be before the start date. In Firebase database security rules this could be:

{
  "journeys": {
    ".validate": "newData.child('startAt').val() > now &&
                  newData.child('endAt').val() > newData.child('startAt').val()"
  }
}

我们在这里进行了额外的检查，您现在也无法预订旅行.这已大大简化，但希望能说明服务器端方面.

We did an extra check here, you can also not book travel before now. This is much simplified, but hopefully illustrates the server-side aspect.

在客户端，您通常会显示一个日历.当用户打开该日历时，您要确保他们无法选择今天之前的日期.您还需要确保结束日期只能在开始日期之后.如果您曾经使用过未实施最后一点的旅游网站，您会知道它很烦人.恼怒的用户转到其他站点.

On the client-side you'll typically show a calendar. When the user opens that calendar, you want to ensure they can't select dates before today. You'll also want to ensure that the end date can only be after the start date. If you've ever used a travel site where this last bit wasn't implemented, you'll know how annoying it it. Annoyed users go to other sites.

这篇关于在Firebase和代码中编写规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！