Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

使用入门：将 App Check 与 reCAPTCHA Enterprise 搭配使用（Flutter 应用）

选择平台：

iOS+ Android Web Flutter

本页介绍了如何在 Flutter 应用中使用 reCAPTCHA Enterprise 提供方来设置 App Check。App Check 有助于确保只有您的应用可以访问项目的后端资源。如需了解详情，请查看我们的概览App Check。

App Check 要求使用 基于分数的 reCAPTCHA 密钥，因此对用户来说是不可见的。这意味着 reCAPTCHA Enterprise 提供方永远不会要求用户进行验证。

如果您的应用场景需要 App CheckApp Check 未实现的 reCAPTCHA Enterprise 功能，或者您想将 App Check 与自己的自定义提供方搭配使用，请参阅实现自定义 App Check 提供方。

1. 设置您的 Firebase 项目

在 Flutter 项目中安装并初始化 Firebase（如果尚未执行此操作）。
在 Google Cloud 控制台中，前往 Fraud Defense 页面，然后针对 reCAPTCHA Enterprise 提供方执行以下操作：
1. 确保您位于正确的项目中（请参阅屏幕顶部的项目选择器）。
2. 如果系统提示，请启用 reCAPTCHA Enterprise API。
3. 根据目标平台创建密钥：
  iOS+
  创建一个 iOS 类型的密钥，并指定应用的软件包 ID（例如 com.example.my_app）。
  
  请务必输入您在 Firebase 项目中创建 Firebase Apple 应用时提供的软件包 ID。软件包 ID 值区分大小写。
  
  对于 App Check，每个软件包 ID 只能对应一个 single reCAPTCHA 密钥。
  Android
  创建一个 Android 类型的密钥，并指定应用的软件包名称（例如 com.example.my_app）。
  
  请务必输入您在 Firebase 项目中创建 Firebase Android 应用时提供的软件包名称。软件包名称值区分大小写。
  
  对于 App Check，每个软件包名称只能对应一个 single reCAPTCHA 密钥。
  Web
  创建一个 Web 类型的密钥，并指定 Web 应用的每个网域。
  
  App Check **不** __支持在超过 250 个网域上提供服务的 Web 应用。
  
  切勿将 localhost 作为网域添加到已部署（或将要部署）到生产环境的 reCAPTCHA 密钥。
  
  取消选择 “使用复选框验证”选项。
  如需查看详细说明，请参阅创建基于分数的 reCAPTCHA 密钥。
4. 记下每个密钥。您需要在 Firebase 控制台中将它们添加到注册流程中。
在 Firebase 控制台中，依次前往 安全性 > App Check。
在应用标签页中，注册每个目标平台应用，以便将 App Check与reCAPTCHA Enterprise提供方搭配使用。您需要提供在 Google Cloud 控制台中获取的密钥。

重要提示：请务必使用证明提供方（例如 reCAPTCHA Enterprise）注册项目的所有应用。为服务启用 强制执行后，只有注册的应用才能访问该服务。
可选: 设置令牌存留时间 (TTL)。

在应用注册设置中，为 App Check提供方颁发的令牌设置自定义存留时间 (TTL)。您可以将 TTL 设置为介于 30 分钟和 7 天之间的任何值。更改此值时，请注意权衡以下几个方面：
- 安全性：较短的 TTL 可以提供更强的安全性，因为它可以缩短攻击者可能滥用已泄露或者已被拦截的令牌的时长。
- 性能：较短的 TTL 意味着您的应用将更频繁地执行证明操作。由于每次执行应用证明过程都会增加网络请求的延迟时间，因此短 TTL 可能会影响应用的性能。
- 配额和费用：较短的 TTL 和频繁的重新证明会更快地耗尽您的配额，而对于付费服务，费用可能更高。请参阅配额和限制。
对于大多数应用而言，默认的 TTL（1 小时）比较合理。请注意，App Check 库会在达到 TTL 时长约一半时刷新令牌。
可选：配置高级设置。
点击保存。

（可选）配置高级设置

当用户打开您的应用时，reCAPTCHA Enterprise 会评估密钥下用户互动所带来的风险等级，并返回一个介于 0.0 和 1.0 之间的得分，增量为 0.1。

0.0 分表示互动风险高，可能具有欺诈性。
1.0 分表示互动风险低，很可能是合法的。

App Check 借助 App Check，您可以配置 应用风险阈值 ，以便可调整您对此风险的容忍度。

对于大多数应用场景，建议使用默认阈值 0.5 。如果您的应用场景需要调整，可以在 Firebase 控制台中为每个应用配置此值（依次前往 安全性 > App Check）。请务必展开并查看下面有关配置应用风险阈值的一些重要注意事项。

查看有关应用风险阈值的重要注意事项

App Check 会使用您配置的应用风险阈值作为用户互动被视为合法所需的最低 reCAPTCHA Enterprise 得分。所有 reCAPTCHA Enterprise 得分严格低于所配置阈值的请求都将被拒绝。调整应用风险阈值时，请注意以下几点：

如果您的 Firebase 项目使用免费 Spark 定价方案，那么在 11 个可能的 reCAPTCHA Enterprise 得分级别中，只有以下 4 个得分级别可用：0.1、0.3、0.7 和 0.9。

在此期间，App Check 将相应地仅允许应用风险阈值设置为 0.1、0.3、0.5、0.7 和 0.9。对于大多数应用场景，仍建议将应用风险阈值设置为 0.5。
- 如需启用所有 11 个 reCAPTCHA Enterprise 得分级别，请将 Cloud Billing 账号与您的项目相关联（这意味着您将 Firebase 项目升级为采用随用随付 Blaze 定价方案）。升级项目后，App Check 将允许您配置介于 0.0 和 1.0 之间的任何应用风险阈值，增量为 0.1。
  
  注意：将 Cloud Billing 账号与项目相关联后，系统会对您的项目触发自动安全审核。如需了解详情，请参阅 reCAPTCHA Enterprise文档。
如需监控应用的reCAPTCHA Enterprise reCAPTCHA Enterprise 高得分和低得分的分布情况，请前往Google CloudGoogle Cloud 控制台中的 **reCAPTCHA Enterprise** 页面，然后选择您的应用使用的密钥。
根据您的容忍度设置适当的应用风险阈值：
- 如果您对应用风险的容忍度较高，请向右移动滑块 以降低应用风险阈值。
  - 不建议使用 0.0 值，因为此设置会停用滥用防护功能。
- 如果您对应用风险的容忍度较低，请向左移动滑块 以提高应用风险阈值。
  - 不建议使用 1.0 值，因为此设置也可能会拒绝不满足此高信任度阈值的合法用户访问。
  警告：为避免干扰合法用户，请在强制执行 App Check 时逐步提高应用风险阈值。请务必监控 App Check 请求指标以验证流量是否未中断。

如需了解更多详细信息，请参阅 reCAPTCHA Enterprise文档，了解移动应用和Web 应用。

2. 将 App Check 插件添加到应用

如需使用 reCAPTCHA Enterprise 提供方，您必须添加相应的 App Check 插件。

从 Flutter 项目的根目录运行以下命令，安装该插件：
```
flutter pub add firebase_app_check
```
完成后，重新构建您的 Flutter 项目：
```
flutter run
```

3. 初始化 App Check

在应用中，您需要先初始化 App Check，然后才能使用其他 Firebase 服务。

import 'package:firebase_core/firebase_core.dart';
import 'package:firebase_app_check/firebase_app_check.dart';
import 'firebase_options.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);
  await FirebaseAppCheck.instance.activate(
    providerWeb: ReCaptchaEnterpriseProvider(WEB_SITE_KEY),
    providerAndroid: const AndroidReCaptchaProvider(ANDROID_SITE_KEY),
    providerApple: const AppleReCaptchaProvider(IOS_SITE_KEY),
  );
  runApp(App());
}

4. 监控指标并启用强制执行

在应用中设置 App Check 后，开始将更新后的应用分发给用户。

更新后的客户端应用会开始将 App Check 令牌随其发出的每个请求一起发送到 Firebase。不过，App Check 不会阻止具有无效令牌的请求，直到强制执行 App Check。

监控指标

**在启用强制执行之前**，请确保这样做不会干扰您的现有合法用户。另一方面，如果您发现自己的应用资源被非法使用，建议您尽快启用强制执行。

为帮助您做出相关决策，建议您查看自己使用的服务的 App Check 指标：

监控 App Check 请求指标，适用于 Firebase AI Logic、SQL Connect、Realtime Database、Cloud Firestore、Cloud Storage、Authentication、Google Identity for iOS、Maps JavaScript API 和 Places API（新版）。
监控 Cloud Functions 的 App Check 请求指标。

启用 App Check 违规处置

在了解 App Check 对用户有何影响并为后续操作做好准备之后，您便可以启用 App Check 强制执行：

为App Check启用违规处置，适用于 Firebase AI Logic、SQL Connect、Realtime Database、Cloud Firestore、Cloud Storage、Authentication、Google Identity for iOS、Maps JavaScript API 和 Places API（新版）。
为 Cloud Functions 启用 App Check 强制执行。

在调试环境中使用 App Check

App Check 会将某些环境归类为无效，例如开发期间来自模拟器 / 模拟器或 localhost 的请求，或者来自持续集成 (CI) 环境的请求。

如需在强制执行 App Check 后在这些类型的环境中运行应用，您需要创建应用的调试 build，该 build 使用 App Check 调试提供方，而不是生产证明提供方。

如需了解详情，请参阅将 App Check 与调试提供程序搭配使用（Flutter 应用）。

价格

App Check 每次应用刷新其 App Check 令牌时，都会代表您创建评估，以验证用户的响应令牌。对于超出免费配额的每项创建的评估，我们会对您的 Firebase 项目收费。如需了解详情，请参阅 reCAPTCHA 价格。

默认情况下，您的应用每 1 小时 会刷新此令牌两次。如需控制应用刷新 App Check 令牌的频率（以及新评估的创建频率），您可以配置令牌 TTL。