监控 App Check 请求指标

将 App Check SDK 添加到应用后,您应在启用 App Check 强制执行之前,先确保这样做不会干扰现有的合法用户。

您可以使用 App Check 请求指标页面这一重要工具,来决定是否为 Realtime Database、Cloud Firestore、Cloud Storage 和 Authentication(Beta 版)启用 App Check 强制执行。

如需查看产品的 App Check 请求指标,请打开 Firebase 控制台的 App Check 部分。例如:

App Check 指标页面的屏幕截图

每个产品的请求指标分为四个类别:

  • 已验证请求是具有有效 App Check 令牌的请求。启用 App Check 强制执行后,只有此类别的请求会成功。

  • 过时的客户端请求是缺少 App Check 令牌的请求。这些请求可能来自应用中未包含 App Check 的旧版 Firebase SDK。

  • 未知来源请求是缺少 App Check 令牌并且看起来不像来自 Firebase SDK 的请求。这些请求可能是使用被盗 API 密钥发出的请求,或者是在未使用 Firebase SDK 的情况下发出的伪造请求。

  • 无效请求是具有无效 App Check 令牌的请求,这些请求可能来自企图冒充您的应用的虚假客户端,也可能来自模拟环境。

这些类别的分布情况可以帮助您决定何时为您的应用启用强制执行。下面列出了一些指南:

  • 如果几乎所有近期请求都来自经过验证的客户端,请考虑启用强制执行,开始保护后端资源。

  • 如果近期请求中有很大一部分来自可能已过时的客户端,为避免干扰用户,请考虑等待更多用户更新应用之后,再启用强制执行。如果对已发布的应用强制执行 App Check,未与 App Check SDK 集成的先前的应用版本将无法使用。

  • 如果您的应用尚未发布,您应立即启用 App Check 强制执行,因为用户还没有使用任何过时的客户端。

后续步骤

在了解 App Check 对用户有何影响并为后续操作做好准备之后,您便可以为 Realtime Database、Cloud Firestore、Cloud Storage 和 Authentication(Beta 版)启用 App Check 强制执行