本页面提供了有关设置 Firebase 项目以及在项目中注册应用的高级别常规最佳实践,您可以参考本页面,以便设置使用不同环境并且清晰明确的开发工作流。熟悉本页中的最佳实践后,请查看我们的常规安全指南。
了解 Firebase 项目的层次结构
此图显示了 Firebase 项目的基本层次结构。以下是关键关系解读:
Firebase 项目就像是一个容器,用于存储您的所有应用以及为项目预配的所有资源和服务。
可以在一个 Firebase 项目中注册一个或多个 Firebase 应用(例如,应用的 iOS 版和 Android 版,或应用的免费版和付费版)。
在同一 Firebase 项目中注册的所有 Firebase 应用可共享并访问为该项目预配的所有相同资源和服务。下面是一些示例:
在同一 Firebase 项目中注册的所有 Firebase 应用共享相同的后端,例如 Firebase Hosting、Authentication、Realtime Database、Cloud Firestore、Cloud Storage 和 Cloud Functions。
在同一 Firebase 项目中注册的所有 Firebase 应用都与同一 Google Analytics 媒体资源相关联,其中每个 Firebase 应用都是该媒体资源中的单独数据流。
Google Cloud 项目位于此层次结构中的什么位置?
上图中未显示的 Firebase 项目层次结构的一个方面是与 Google Cloud 项目的关系。Firebase 项目实际上只是一个启用了额外的 Firebase 特定配置和服务的 Google Cloud 项目。请注意,在同一 Firebase 项目中注册的所有应用还可共享并访问所有相同的 Google Cloud 资源和服务。
如需详细了解 Firebase 与 Google Cloud 之间的关系,请参阅了解 Firebase 项目
在 Firebase 项目中注册应用变体
以下是在 Firebase 项目中注册应用变体的一些重要提示:
确保在 Firebase 项目注册的所有应用在最终用户眼里都是同一应用的平台变体。也即,在同一个 Firebase 项目中注册同一应用或游戏的 iOS、Android 和 Web 版本。
如果您有多个可以共享相同 Firebase 资源的 build 变体,请在同一个 Firebase 项目中注册这些变体。例如,同一项目中的博客和 Web 应用,或同一项目中同一应用的免费版和付费版。
如果您有多个基于版本状态的 build 变体(而不是像上文那样基于常见的最终用户活动或访问),则可以在单独的 Firebase 项目中分别注册每个变体。例如,您的调试 build 与发布 build - 请在其各自的 Firebase 项目中分别注册每个 build。
基于版本状态的 build 不应共享相同的 Firebase 资源,因为这有可能会给您的调试数据造成污染,甚至导致您的生产环境数据被覆盖。
其中每个 build 变体的平台变体都应在同一 Firebase 项目中。 例如,在“dev”Firebase 项目中同时注册 iOS 和 Android 调试 build,因为它们都可以与相同的非生产环境数据和资源进行交互。
避免多租户
多租户可能会导致严重的配置和数据隐私问题,包括分析聚合、共享身份验证、过于复杂的数据库结构以及安全规则难度增加等意外问题。
通常,如果一组应用并非共享相同的数据和配置,则强烈建议您在不同的 Firebase 项目中注册每个应用。
例如,如果您开发一个白标应用,则每个有独立标签的应用都应该有自己的 Firebase 项目,并且该标签的 iOS 和 Android 版本应位于同一 Firebase 项目中。每个有独立标签的应用都不应该(出于保护隐私方面的原因)与其他应用共享数据。
后续步骤
查看针对不同环境的常规安全准则。您需要确保每个环境及其数据都安全无虞。
查看 Firebase 发布核对清单。