אחרי שמוסיפים את App Check SDK לאפליקציה, אבל לפני שמפעילים את האכיפה של App Check, צריך לוודא שהפעולה הזו לא תשבש את השימוש של המשתמשים הלגיטימיים הקיימים.
כדי לקבל החלטה לגבי Data Connect, Firebase AI Logic, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity for iOS, Maps JavaScript API ו-Places API (חדש), כדאי להשתמש במסך מדדי הבקשות App Check.
כדי לראות את מדדי הבקשות של App Check למוצר, פותחים את הקטע App Check במסוף Firebase. לדוגמה:
מדדי הבקשות לכל מוצר מחולקים לארבע קטגוריות:
בקשות מאומתות הן בקשות שיש להן אסימון App Check תקין. אחרי שמפעילים את האכיפה של App Check, רק בקשות בקטגוריה הזו יצליחו.
בקשות מלקוח מיושן הן בקשות שחסר בהן App Check token. יכול להיות שהבקשות האלה מגיעות מגרסה ישנה יותר של Firebase SDK, לפני ש-App Check נכלל באפליקציה.
בקשות ממקור לא ידוע הן בקשות שחסר בהן אסימון App Check, ולא נראה שהן מגיעות מ-Firebase SDK. יכול להיות שהבקשות האלה נשלחו באמצעות מפתחות API גנובים או שהן מזויפות ונשלחו ללא Firebase SDK.
בקשות לא חוקיות הן בקשות עם טוקן App Checkלא חוקי, שיכול להיות שמקורו בלקוח לא אותנטי שמנסה להתחזות לאפליקציה שלכם, או בסביבות מדומה.
החלוקה של הקטגוריות האלה באפליקציה שלכם צריכה לעזור לכם להחליט מתי להפעיל את האכיפה. הנה כמה הנחיות:
אם כמעט כל הבקשות האחרונות מגיעות מלקוחות מאומתים, כדאי להפעיל את האכיפה כדי להתחיל להגן על משאבי הקצה העורפי.
אם חלק משמעותי מהבקשות האחרונות מגיע מלקוחות שכנראה לא מעודכנים, כדי לא לשבש את חוויית המשתמשים, מומלץ לחכות עד שיותר משתמשים יעודכנו באפליקציה לפני שמפעילים את האכיפה. החלת App Check על אפליקציה שפורסמה תשבור גרסאות קודמות של האפליקציה שלא משולבות עם App Check SDK.
אם האפליקציה שלכם עדיין לא הושקה, כדאי להפעיל את App Check האכיפה באופן מיידי, כי אין לקוחות לא מעודכנים בשימוש.
השלבים הבאים
אחרי שתבינו איך App Check ישפיע על המשתמשים שלכם ותהיו מוכנים להמשיך, תוכלו להפעיל את האכיפה של App Check עבור Data Connect, Firebase AI Logic, Realtime Database, Cloud Firestore, Cloud Storage, Authentication, Google Identity ל-iOS, Maps JavaScript API ו-Places API (חדש).