如何实现 Firebase 服务器端安全

Question

我目前正在开发一个新的谷歌聚合物网络应用程序，想知道是否应该使用 firebase 作为后端/数据库。我看了一下这个项目，做了一些测试应用，真的很喜欢它！但要完全说服我，firebase 是我需要回答的以下问题：

1. 我有点担心安全性：所以，我知道，firebase 使用读取、写入和验证来实现服务器端安全性。从示例中，我注意到验证基本上是一个单行 JS 脚本，它代表一个“if”。当我计划构建一个 Web 电子商务应用程序时，我需要验证相当多的输入。是否有可能将验证外包到一个单独的文件中，使其更具可读性？我还想知道，是否有可能通过单元测试来测试这些服务器端验证？

2. 我目前不能 100% 确定，firebase 可以涵盖我们所有的用例。对某些关键功能使用“正常”后端，然后将后端的数据保存在 firebase 中，是否有可能/一个好的解决方案？

3. 我看到了一些很好的用于 firebase 的聚合物元素。聚合物/网络组件是否 100% 支持 firebase？

4. 是否有其他方法（如 Java 方法）来实现服务器业务逻辑？

5. 有没有办法定义更新脚本，以便可以轻松地将新版本推送到生产中？

感谢和亲切的问候

马克

Answer 1

因此，我询问了 firebase 支持并得到了以下答案：

很高兴见到你。

1. 我有点担心安全性：所以，我知道，firebase 使用读取、写入和验证来实现服务器端安全性。从示例中，我注意到验证基本上是一个单行 JS 脚本，它代表一个“if”。当我计划构建一个 Web 电子商务应用程序时，我需要验证相当多的输入。是否有可能将验证外包到一个单独的文件中，使其更具可读性？我还想知道，是否有可能通过单元测试来测试这些服务器端验证？

您可以使用我们的安全规则语言实施极其复杂和有效的规则。您可以在托管部署过程中或通过 REST API 部署安全规则。不可能将内容分解为服务器上的多个文件，但您当然可以构建自己的过程，将多个文件合并为单个 JSON 结果。

2. 我目前不能 100% 确定，firebase 可以涵盖我们所有的用例。对某些关键功能使用“正常”后端，然后将后端的数据保存在 firebase 中，是否有可能/一个好的解决方案？

一般来说，同步 Firebase 和 SQL 后端不是很实用，也不能很好地翻译。它也可能完全是多余的。

3. 我看到了一些很好的用于 firebase 的聚合物元素。聚合物/网络组件是否 100% 支持 firebase？

在这种情况下，我不知道 100% 支持意味着什么。我们提供了一个 JavaScript SDK，因此它们应该可以很好地协同工作。

4. 是否有其他方法（如 Java 方法）来实现服务器业务逻辑？

我们提供 Java、Objective-C/Swift、Android、Node.js、JavaScript 和用于其他语言的 REST API 的官方 SDK。

5. 有没有办法定义更新脚本，以便可以轻松地将新版本推送到生产中？

我不确定这意味着什么。答案很可能是否定的，因为我们不提供构建过程或任何工具来发布您的软件。

我希望这有帮助！

我回答了：

谢谢你的信息，对我帮助很大！在阅读了您对问题 5 的回答后，我脑海中又出现了一个问题：... 5. 有没有办法定义更新脚本，以便可以轻松地将新版本推送到生产中？我不确定这意味着什么。答案很可能是否定的，因为我们不提供构建过程或任何工具来发布您的软件。

是否有关于如何处理数据库模式的最佳实践？在我的情况下，我只有一个 Web 应用程序（没有应用程序等）......我预计数据库会随着时间的推移和发布而发生巨大变化。如果有必要，我应该编写 JS 逻辑来检查当前数据库版本并更新它吗？也许这会成为一个不错的功能......

例如：我部署了应用程序的 1.0 版，一切正常。经过 3 个月的编程，我注意到用户数据需要进一步的属性：地址，这是一个“非空”属性。我现在部署我的应用程序的 2.0 版，每个新注册用户都有一个地址，但旧用户（从 1.0 版开始）没有此字段或值。

我该如何处理？

支持回复：

嗨，马克，

这里没有最佳实践，但您的想法似乎相当合理。您可能不需要检查您的 JavaScript。您可能可以在用户的​​配置文件中存储一个版本号，当他们升级到最新软件时，您可以在他们的配置文件数据中进行升级。

然后您的验证规则可以使用如下内容：

{
   "user": {
       ".write": "newData.hasChild('address') || newData.child('appVersion') < 4",
       "address": {
            ".validate": "newData.isString() && newData.val().length < 1000"
       }
   }
}

因此，如果您担心版本控制，这可用于处理遗留版本。

我从开发人员那里看到的另一种流行方法是通过复制数据进行中间升级。因此，您发布了一个中间版本，该版本使用更新的数据结构写入旧路径和新路径（这使应用程序为老用户工作，直到他们升级）。一旦合理百分比的客户端升级，然后发布不再对旧结构和新结构进行双重写入的最终版本。

当然，扁平化数据虽然会使连接和获取数据变得更加痛苦，但由于模块化数据结构更容易适应变化，因此升级会更加容易。而且，自然地，将各种记录包装在一个类中的实用设计（例如，带有 getter/setter 方法的 UserProfile 类）使转换更简单，因为您可以轻松地在一个地方进行版本控制。

希望这对某人有所帮助:)