אחרי שמוסיפים את ה-SDK של App Check לאפליקציה, אבל לפני שמפעילים את האכיפה של App Check, צריך לוודא שהפעולה הזו לא תפריע למשתמשים החוקיים הקיימים.
כלי חשוב שיעזור לכם לקבל את ההחלטה הזו לגבי Realtime Database, Cloud Firestore, Cloud Storage, Authentication (בטא) ו-Vertex AI in Firebase הוא המסך של מדדי הבקשות של App Check.
כדי להציג את מדדי הבקשות של App Check למוצר מסוים, פותחים את הקטע App Check במסוף Firebase. לדוגמה:
דף המדדים של בדיקת האפליקציה"
class="screenshot">
מדדי הבקשות של כל מוצר מחולקים לארבע קטגוריות:
בקשות מאומתות הן בקשות עם אסימון App Check תקין. אחרי שמפעילים את האכיפה של App Check, רק בקשות בקטגוריה הזו יתקבלו.
בקשות לקוח מיושן הן בקשות שבהן חסר אסימון App Check. יכול להיות שהבקשות האלה מגיעות מגרסה ישנה יותר של ה-Firebase SDK, לפני ש-App Check נכלל באפליקציה.
בקשות ממקור לא ידוע הן בקשות שבהן חסר אסימון App Check, ושלא נראה שהן מגיעות מ-Firebase SDK. אלה יכולות להיות בקשות שנשלחו באמצעות מפתחות API גנובים או בקשות מזויפות שנשלחו ללא Firebase SDK.
בקשות לא חוקיות הן בקשות עם טוקן App Check לא חוקי. הן יכולות להגיע מלקוח לא אותנטי שמנסה להתחזות לאפליקציה שלכם, או מסביבות מופעלות.
חלוקת הקטגוריות האלה באפליקציה שלכם תעזור לכם להחליט מתי להפעיל את האכיפה. ריכזנו כאן כמה הנחיות:
אם כמעט כל הבקשות האחרונות הגיעו מלקוחות מאומתים, כדאי להפעיל את האכיפה כדי להתחיל להגן על משאבי הקצה העורפי.
אם חלק משמעותי מהבקשות האחרונות מגיעות מלקוחות שסביר להניח שהגרסה שלהם לא עדכנית, כדי לא להפריע למשתמשים, מומלץ להמתין עד שיותירו משתמשים שיעדכנו את האפליקציה לפני שמפעילים את האכיפה. אכיפת App Check באפליקציה שפורסמה תגרום לשיבושים בגרסאות קודמות של האפליקציה שלא משולבות עם App Check SDK.
אם האפליקציה שלכם עדיין לא הושקה, כדאי להפעיל את האכיפה של App Check באופן מיידי, כי אין לקוחות לא מעודכנים בשימוש.
השלבים הבאים
אחרי שתבין איך App Check ישפיע על המשתמשים שלך ותהיה מוכן להמשיך, אפשר להפעיל את אכיפת App Check ב-Realtime Database, ב-Cloud Firestore, ב-Cloud Storage, ב-Authentication (בטא) וב-Vertex AI in Firebase.