‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

תחילת העבודה עם App Check ו-reCAPTCHA Enterprise באפליקציות Flutter

בחירת פלטפורמה:

‫iOS+‎ Android Web Flutter

בדף הזה מוסבר איך להגדיר את App Check באפליקציית Flutter באמצעות ספק reCAPTCHA Enterprise. App Check עוזרת לוודא שרק האפליקציה שלכם יכולה לגשת למשאבי הקצה העורפי של הפרויקט. מידע נוסף זמין בסקירה הכללית של App Check.

‫App Check דורש שימוש במפתחות מבוססי ניקוד reCAPTCHA, ולכן הוא לא גלוי למשתמשים. המשמעות היא שספק reCAPTCHA Enterprise לא יבקש מהמשתמשים לפתור אתגר בשום שלב.

אם תרחיש השימוש שלכם דורש תכונות של reCAPTCHA Enterprise שלא מיושמות על ידי App Check, או אם אתם רוצים להשתמש ב-App Check עם ספק מותאם אישית משלכם, כדאי לעיין במאמר בנושא הטמעה של ספק App Check מותאם אישית.

1. הגדרת פרויקט Firebase

אם עדיין לא עשיתם זאת, אתם צריכים להתקין את Firebase בפרויקט Flutter ולהפעיל אותו.
במסוף Google Cloud, עוברים לדף Fraud Defense ומבצעים את הפעולות הבאות עבור הספק reCAPTCHA Enterprise:
1. מוודאים שאתם נמצאים בפרויקט הנכון (אפשר לראות את בורר הפרויקטים בחלק העליון של המסך).
2. אם מופיעה בקשה, מפעילים את ה-API של reCAPTCHA Enterprise.
3. יוצרים מפתח על סמך פלטפורמת היעד:
  ‫iOS+‎
  יוצרים מפתח מסוג iOS ומציינים את מזהה החבילה של האפליקציה (לדוגמה, com.example.my_app).
  
  חשוב לוודא שהזנתם את אותו מזהה חבילה שסיפקתם כשנוצרה אפליקציית Apple ב-Firebase בפרויקט Firebase. הערך של מזהה החבילה הוא תלוי אותיות רישיות.
  
  במקרה של App Check, כל מזהה חבילה יכול להתאים רק למפתח reCAPTCHA אחד.
  Android
  יוצרים מפתח מסוג Android ומציינים את שם החבילה של האפליקציה (לדוגמה, com.example.my_app).
  
  חשוב לוודא שהזנתם את אותו שם חבילה שסיפקתם כשנוצרה אפליקציית Firebase ל-Android בפרויקט Firebase. הערך של שם החבילה הוא תלוי אותיות רישיות (case-sensitive).
  
  במקרה של App Check, כל שם חבילה יכול להתאים רק למפתח reCAPTCHA אחד.
  אינטרנט
  יוצרים מפתח מסוג Web ומציינים כל אחד מהדומיינים של אפליקציות האינטרנט.
  
  ‫App Check לא תומך באפליקציות אינטרנט שפועלות ביותר מ-250 דומיינים.
  
  אל תוסיפו אף פעם את localhost כדומיין למפתח reCAPTCHA שמוטמע בסביבת הייצור (או שיוטמע בה).
  
  משאירים את האפשרות 'שימוש באתגר תיבת סימון' לא מסומנת.
  הוראות מפורטות זמינות במאמר בנושא יצירת מפתחות reCAPTCHA שמבוססים על ניקוד.
4. רושמים בצד כל מפתח. צריך להוסיף אותם לתהליך ההרשמה במסוף Firebase.
במסוף Firebase, עוברים אל Security (אבטחה) >‏ App Check (בדיקת אפליקציות).
בכרטיסייה אפליקציות, רושמים כל אחת מהאפליקציות של פלטפורמת היעד לשימוש ב-App Check עם ספק reCAPTCHA Enterprise. תצטרכו לספק את המפתח שקיבלתם במסוף Google Cloud.

חשוב: הקפידו לרשום את כל האפליקציות של הפרויקט אצל ספק אימות (כמו reCAPTCHA Enterprise). אחרי הפעלת אכיפה בשירות מסוים, רק אפליקציות רשומות יוכלו לגשת לשירות.
אופציונלי: מגדירים את אורך החיים (TTL) של האסימון.

בהגדרות רישום האפליקציה, מגדירים אורך חיים (TTL) מותאם אישית לטוקנים של App Check שהונפקו על ידי הספק. אפשר להגדיר את ה-TTL לכל ערך בין 30 דקות ל-7 ימים. כשמשנים את הערך הזה, חשוב לשים לב לשיקולים הבאים:
- אבטחה: ערכי TTL קצרים יותר מספקים אבטחה חזקה יותר, כי הם מצמצמים את חלון הזמן שבו תוקף יכול לנצל לרעה אסימון שדלף או נחטף.
- ביצועים: ערכי TTL קצרים יותר אומרים שהאפליקציה תבצע אימות בתדירות גבוהה יותר. תהליך אימות האפליקציה מוסיף זמן אחזור לבקשות רשת בכל פעם שהוא מתבצע, ולכן ערך TTL קצר יכול להשפיע על ביצועי האפליקציה.
- מכסת השימוש והעלות: ערכי TTL קצרים ואימות חוזר תכוף מרוקנים את מכסת השימוש מהר יותר, ובשירותים בתשלום, עלולים לייקר את העלות. מידע נוסף זמין במאמר מכסות ומגבלות.
ערך ברירת המחדל של TTL הוא שעה אחת, וזה ערך סביר לרוב האפליקציות. הערה: ספריית App Check מרעננת את האסימונים בערך במחצית משך ה-TTL.
אופציונלי: מגדירים הגדרות מתקדמות.
לוחצים על שמירה.

(אופציונלי) הגדרת הגדרות מתקדמות

כשמשתמש פותח את האפליקציה, reCAPTCHA Enterprise מעריך את רמת הסיכון שהאינטראקציה של המשתמש מייצגת בהתאם למפתח, ומחזיר ציון בין 0.0 ל-1.0, במרווחים של 0.1.

ציון של 0.0 מציין שהאינטראקציה מהווה סיכון גבוה ויכול להיות שהיא הונאה.
ציון של 1.0 מציין שהאינטראקציה מהווה סיכון נמוך, וסביר מאוד שהיא לגיטימית.

App Check מאפשר לכם להגדיר סף סיכון לאפליקציה כדי שתוכלו להתאים את הסבילות שלכם לסיכון הזה.

ברוב תרחישי השימוש, מומלץ להשתמש בערך הסף שמוגדר כברירת מחדל, 0.5. אם תרצו לשנות את הערך הזה בהתאם לתרחיש השימוש שלכם, תוכלו להגדיר אותו לכל אחת מהאפליקציות שלכם במסוף Firebase (נכנסים אל אבטחה > App Check). חשוב להרחיב את השיקולים החשובים לגבי הגדרת סף הסיכון של האפליקציה שבהמשך ולעיין בהם.

שיקולים חשובים לגבי סף הסיכון של האפליקציה

‫App Check משתמש בסף הסיכון שהגדרתם לאפליקציה כציון המינימלי reCAPTCHA Enterprise שנדרש כדי שאינטראקציה של משתמש תיחשב לגיטימית. כל הציונים של reCAPTCHA Enterprise שקטנים מהסף שהגדרתם יידחו. כשמשנים את סף הסיכון של האפליקציה, חשוב לשים לב לנקודות הבאות:

אם הפרויקט שלכם ב-Firebase נמצא בתוכנית התמחור Spark ללא עלות, מתוך 11 רמות הניקוד האפשריות reCAPTCHA Enterprise, רק ארבע רמות הניקוד הבאות זמינות: 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 Cloud ובוחרים את המפתח שבו האפליקציה משתמשת.
הגדרת סף הסיכון של האפליקציה בהתאם למידת הסבילות שלכם:
- אם אתם מוכנים לקבל סיכון גבוה מאפליקציות, מזיזים את פס ההזזה שמאלה כדי להקטין את סף הסיכון של האפליקציה.
  - לא מומלץ להשתמש בערך 0.0, כי ההגדרה הזו משביתה את אמצעי ההגנה מפני ניצול לרעה.
- אם יש לכם סבילות לסיכון נמוכה באפליקציות, מזיזים את פס ההזזה שמאלה כדי להגדיל את סף הסיכון של האפליקציה.
  - לא מומלץ להגדיר ערך של 1.0, כי ההגדרה הזו עלולה למנוע גישה ממשתמשים לגיטימיים שלא עומדים בסף הגבוה הזה של מהימנות.
  אזהרה: כדי לא לשבש את חוויית המשתמש של משתמשים לגיטימיים, צריך להגדיל בהדרגה את סף הסיכון של האפליקציה כשמפעילים את App Check. תמיד עוקבים אחרי App Checkמדדי הבקשות כדי לוודא שלא חלו שיבושים בתנועה.

פרטים נוספים זמינים במסמכי התיעוד של reCAPTCHA Enterprise בנושא אפליקציות לנייד ואפליקציות לאינטרנט.

2. הוספת הפלאגין App Check לאפליקציה

כדי להשתמש בספק reCAPTCHA Enterprise, צריך להוסיף את הפלאגין App Check המתאים.

מהרמה הבסיסית (root) של פרויקט 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 (חדש).
מעקב אחרי מדדי בקשות של App Check עבור Cloud Functions.

הפעלת האכיפה של 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 (חדש).
הפעלת אכיפה של App Check עבור Cloud Functions.

שימוש ב-App Check בסביבות ניפוי באגים

‫App Check מסווגת סביבות מסוימות כלא תקינות, כמו בקשות מאמולטור או מסימולטור, או מ-localhost במהלך פיתוח, או מסביבת אינטגרציה רציפה (CI).

כדי להריץ את האפליקציה בסביבות מהסוגים האלה אחרי שאמצעי האכיפה של App Check יופעלו, תצטרכו ליצור גרסת ניפוי באגים של האפליקציה שמשתמשת בApp Check ספק ניפוי באגים במקום בספק אימות ייצור.

פרטים נוספים זמינים במאמר בנושא שימוש ב-App Check עם ספק הניפוי באגים באפליקציות Flutter.

תמחור

‫App Check יוצרת הערכה בשמכם כדי לאמת את טוקן התגובה של המשתמש בכל פעם שהאפליקציה מרעננת את הטוקן של App Check. החיוב על כל הערכה שתיצרו מעבר למכסת השימוש ללא עלות יופיע בפרויקט Firebase. פרטים נוספים מופיעים בקטע reCAPTCHAתמחור.

כברירת מחדל, האפליקציה תרענן את הטוקן הזה פעמיים בכל שעה. כדי לשלוט בתדירות שבה האפליקציה מרעננת את אסימוני App Check (ובכך בתדירות שבה נוצרים הערכות חדשות), אתם יכולים להגדיר את ה-TTL של האסימון.