תחילת השימוש ב-App Check עם reCAPTCHA Enterprise באפליקציות אינטרנט

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

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

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

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

1. אם עדיין לא עשיתם זאת, מוסיפים את Firebase לפרויקט JavaScript.

2. פותחים את הקטע reCAPTCHA Enterprise במסוף Cloud ומבצעים את הפעולות הבאות:

   1. אם תתבקשו להפעיל את reCAPTCHA Enterprise API, תצטרכו לעשות זאת.
   2. יוצרים מפתח מסוג אתר. צריך לציין את הדומיינים שבהם מתארחת אפליקציית האינטרנט. חשוב להשאיר את האפשרות לא מסומנת 'שימוש באתגר תיבת סימון'.

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

   בדרך כלל צריך לרשום את כל האפליקציות בפרויקט, כי אחרי שמפעילים אכיפה של מוצר Firebase, רק אפליקציות רשומות יכולות לגשת למשאבי ה-Backend של המוצר.

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

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

   ערך ברירת המחדל של TTL הוא שעה אחת, והוא מתאים לרוב האפליקציות. הערה: ספריית App Check מרעננת את האסימונים בערך במחצית משך ה-TTL.

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

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

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

פרטים

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

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

• כדי לעקוב אחרי ההתפלגות של ציונים גבוהים ונמוכים ב-reCAPTCHA Enterprise באפליקציית האינטרנט שלכם, נכנסים לדף reCAPTCHA Enterprise במסוף Google Cloud ובוחרים את מפתח האתר שבו נעשה שימוש באפליקציית האינטרנט.

• אם אתם רוצים להגדיר סף סיכון נמוך לאפליקציות, מזיזים את פס ההזזה שמאלה כדי להגדיל את סף הסיכון לאפליקציות.

  • לא מומלץ להגדיר ערך של 1.0, כי ההגדרה הזו עלולה גם למנוע גישה ממשתמשים לגיטימיים שלא עומדים בסף הגבוה הזה של מהימנות.

• אם אתם מוכנים לקבל סיכון גבוה באפליקציות, מזיזים את הסליידר שמאלה כדי להקטין את סף הסיכון של האפליקציות.

  • לא מומלץ להשתמש בערך 0.0, כי ההגדרה הזו משביתה את ההגנה מפני ניצול לרעה.

פרטים נוספים זמינים במאמרי העזרה של reCAPTCHA Enterprise.

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

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

3. אתחול App Check

מוסיפים את קוד האתחול הבא לאפליקציה, לפני שניגשים לשירותי Firebase. תצטרכו להעביר את מפתח האתר של reCAPTCHA Enterprise שיצרתם במסוף Cloud אל activate().

import { initializeApp } from "firebase/app";
import { initializeAppCheck, ReCaptchaEnterpriseProvider } from "firebase/app-check";

const app = initializeApp({
  // Your Firebase configuration object.
});

// Create a ReCaptchaEnterpriseProvider instance using your reCAPTCHA Enterprise
// site key and pass it to initializeAppCheck().
const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaEnterpriseProvider(/* reCAPTCHA Enterprise site key */),
  isTokenAutoRefreshEnabled: true // Set to true to allow auto-refresh.
});

firebase.initializeApp({
  // Your Firebase configuration object.
});

// Create a ReCaptchaEnterpriseProvider instance using your reCAPTCHA Enterprise
// site key and pass it to activate().
const appCheck = firebase.appCheck();
appCheck.activate(
  new firebase.appCheck.ReCaptchaEnterpriseProvider(
    /* reCAPTCHA Enterprise site key */
  ),
  true // Set to true to allow auto-refresh.
);

השלבים הבאים

אחרי שמתקינים את ספריית App Check באפליקציה, פורסים אותה.

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

מעקב אחרי מדדים והפעלת אכיפה

עם זאת, לפני שמפעילים את האכיפה, צריך לוודא שהפעולה הזו לא תשפיע על משתמשים קיימים לגיטימיים. מצד שני, אם אתם רואים שימוש חשוד במשאבי האפליקציה, כדאי להפעיל את האכיפה מוקדם יותר.

כדי לקבל החלטה מושכלת, אפשר לעיין במדדים של App Check השירותים שבהם אתם משתמשים:

• מעקב אחרי מדדי בקשות של App Check עבור Firebase AI Logic,‏ Data 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,‏ Data 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 בדרך כלל לא מסווגת כסביבה תקפה, כמו בסביבה מקומית במהלך פיתוח או בסביבת שילוב רציף (CI), אתם יכולים ליצור גרסת ניפוי באגים של האפליקציה שמשתמשת בספק ניפוי הבאגים של App Check במקום בספק אימות אמיתי.

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

הערה לגבי עלות

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

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