שימוש ב-App Check לאבטחת מפתח ה-API
Firebase App Check מספק הגנה על קריאות מהאפליקציה שלכם לפלטפורמת מפות Google על ידי חסימה של תעבורת נתונים שמגיעה ממקורות שאינם אפליקציות חוקיות. לשם כך, הוא מחפש טוקן מספק אימות כמו reCAPTCHA Enterprise. שילוב האפליקציות שלכם עם App Check עוזר להגן מפני בקשות זדוניות, כך שלא תחויבו על קריאות API לא מורשות.
האם בדיקת האפליקציות מתאימה לי?
מומלץ להשתמש ב-App Check ברוב המקרים, אבל אין צורך ב-App Check או שהוא לא נתמך במקרים הבאים:
- אתם משתמשים ב-Places SDK המקורי. יש תמיכה ב-App Check רק ב-Places SDK (חדש).
- אפליקציות פרטיות או ניסיוניות. אם האפליקציה שלכם לא זמינה לכולם, אין צורך לבצע בדיקת אפליקציות.
- אם האפליקציה שלכם משמשת רק לשרת-לשרת, אין צורך בבדיקה של האפליקציה. עם זאת, אם לקוחות ציבוריים (כמו אפליקציות לנייד) משתמשים בשרת שמתקשר עם GMP, מומלץ להשתמש ב-App Check כדי להגן על השרת הזה במקום ב-GMP.
סקירה כללית של שלבי ההטמעה
באופן כללי, אלה השלבים שצריך לבצע כדי לשלב את האפליקציה עם App Check:
- מוסיפים את Firebase לאפליקציה.
- הוספה של ספריית App Check ואיפוס שלה.
- מוסיפים את ספק האסימונים לאפליקציה.
- מפעילים את ממשקי ה-API של Places ושל בדיקת האפליקציות.
- מפעילים את ניפוי הבאגים.
- מעקב אחר הבקשות של האפליקציה והחלטות לגבי אכיפת המדיניות.
אחרי שתשלימו את השילוב עם App Check, תוכלו לראות מדדי תנועה לקצה העורפי במסוף Firebase. המדדים האלה מספקים פירוט של הבקשות לפי העובדה אם הן מלוות באסימון תקף של בדיקת האפליקציה. מידע נוסף זמין במסמכי התיעוד של Firebase App Check.
כשאתם בטוחים שרוב הבקשות מגיעות ממקורות לגיטימיים ושהמשתמשים עדכנו לגרסה האחרונה של האפליקציה שכוללת את ההטמעה שלכם של App Check, אתם יכולים להפעיל את האכיפה. אחרי שהאכיפה תופעל, מערכת App Check תדחה את כל התנועה ללא אסימון תקף של App Check.
שיקולים בתכנון שילוב של App Check
אלה כמה דברים שכדאי להביא בחשבון כשמתכננים את השילוב:
- אחד מספקי האימות שאנחנו ממליצים עליהם, reCAPTCHA Enterprise, גובה תשלום על יותר מ-10,000 בדיקות בחודש.
לספק האימות השני שאנחנו ממליצים עליו, reCAPTCHA v3, יש מכסה, ולאחריה התנועה לא תעבור הערכה.
אפשר לבחור להשתמש בספק אימות בהתאמה אישית, אבל זהו תרחיש לדוגמה מתקדם. מידע נוסף זמין במסמכי התיעוד של App Check.
-
למשתמשים באפליקציה תהיה זמן אחזור מסוים בזמן ההפעלה. עם זאת, לאחר מכן, כל אימות מחדש תקופתי יתבצע ברקע, והמשתמשים לא אמורים לחוות יותר זמן אחזור. משך זמן האחזור המדויק בזמן ההפעלה תלוי בספק האימות שבחרתם.
משך הזמן שבו הטוקן של App Check תקף (אורך החיים, או TTL) קובע את תדירות האימותים מחדש. אפשר להגדיר את משך הזמן הזה במסוף Firebase. אימות מחדש מתבצע כאשר חולף בערך חצי מתקופת ה-TTL. למידע נוסף, אפשר לעיין במסמכי העזרה של Firebase של ספק האימות.
שילוב האפליקציה עם App Check
דרישות מוקדמות ודרישות
- אפליקציה עם הגרסה השבועית או הרבעונית האחרונה של Maps JS API, ספריית הליבה וספריית המקומות.
- פרויקט ב-Cloud שבו הופעלו ממשקי ה-API של מפות Google JS ו-Places API (החדש).
- עליכם להיות הבעלים של האפליקציה במסוף Cloud.
- עליכם למצוא את מזהה הפרויקט של האפליקציה במסוף Cloud.
שלב 1: מוסיפים את Firebase לאפליקציה
פועלים לפי ההוראות במסמכי התיעוד למפתחים של Firebase כדי להוסיף את Firebase לאפליקציה.
שלב 2: מוסיפים את הספרייה של App Check ומפעילים את App Check
ב-Firebase יש הוראות לכל ספק אימות שמוגדר כברירת מחדל. בהוראות האלה מוסבר איך להגדיר פרויקט Firebase ולהוסיף את הספרייה של App Check לאפליקציה. כדי לאתחל את App Check, פועלים לפי דוגמאות הקוד שסופקו.
שלב 3: טעינת הספריות של Maps JS API
מעמיסים את הספריות core, Maps ו-Places כפי שמתואר בקטע הקוד הבא. מידע נוסף והוראות מפורטות זמינים במסמכי העזרה בנושא סיווג מקומות בממשק API של JavaScript במפות Google.
async function init() { const {Settings} = await google.maps.importLibrary('core'); const {Map} = await google.maps.importLibrary('maps'); const {Place} = await google.maps.importLibrary('places'); }
שלב 4: מאתחלים את ממשקי ה-API של Places ושל בדיקת האפליקציות
- מפעילים את App Check באמצעות קובץ התצורה שסופק על ידי מסוף Firebase.
- מוודאים שהבקשות ל-Maps JS API מלוות באסימונים של בדיקת האפליקציה:
async function init() { const {Settings} = await google.maps.importLibrary('core'); const {Map} = await google.maps.importLibrary('maps'); const {Place} = await google.maps.importLibrary('places'); const app = initializeApp({ // Your firebase configuration object }); // Pass your reCAPTCHA Enterprise site key to initializeAppCheck(). const appCheck = initializeAppCheck(app, { provider: new ReCaptchaEnterpriseProvider( 'abcdefghijklmnopqrstuvwxy-1234567890abcd', ), // Optional argument. If true, the SDK automatically refreshes App Check // tokens as needed. isTokenAutoRefreshEnabled: true, }); Settings.getInstance().fetchAppCheckToken = () => getToken(appCheck, /* forceRefresh = */ false); // Make a Places JS request const place = new Place({id: 'ChIJN5Nz71W3j4ARhx5bwpTQEGg'}); await place.fetchFields({fields: ['*']}); // Load a map map = new Map(document.getElementById("map"), { center: { lat: 37.4161493, lng: -122.0812166 }, zoom: 8, }); }
שלב 5: מפעילים את ניפוי הבאגים (אופציונלי)
אם אתם רוצים לפתח ולבדוק את האפליקציה באופן מקומי, או להריץ אותה בסביבת שילוב רצוף (CI), אתם יכולים ליצור גרסה של האפליקציה לצורכי ניפוי באגים שמשתמשת בסוד לניפוי באגים כדי לקבל אסימונים תקינים של App Check. כך תוכלו להימנע משימוש בספקים אמיתיים של אימות ב-build לניפוי באגים.
כדי לבדוק את האפליקציה באופן מקומי:
- מפעילים את ספק ניפוי הבאגים למטרות פיתוח.
- תקבלו UUID4 אקראי שנוצר באופן אוטומטי (שנקרא _אסימון ניפוי באגים_ במסמכי העזרה של App Check) מהיומנים של ניפוי הבאגים של ה-SDK. מוסיפים את האסימון הזה למסוף Firebase.
- מידע נוסף והוראות מפורטות זמינים במסמכי התיעוד של App Check.
כדי להריץ את האפליקציה בסביבת CI:
- יוצרים UUID4 אקראי במסוף Firebase.
- מוסיפים את UUID4 כאסימון ניפוי באגים, ולאחר מכן מעתיקים אותו למאגר סודות שאליו תיהיה גישה לבדיקות ה-CI בכל הפעלת בדיקה.
- מידע נוסף והוראות מפורטות זמינים במסמכי התיעוד של App Check.
שלב 6: מעקב אחר הבקשות של האפליקציה והחלטות לגבי אכיפה
לפני שמתחילים לאכוף את המדיניות, חשוב לוודא שלא תגרמו להפרעה למשתמשים חוקיים באפליקציה. כדי לעשות זאת, עוברים למסך המדדים של בדיקת האפליקציה כדי לראות איזה אחוז מהתנועה באפליקציה מאומתת, לא עדכנית או לא חוקית. אחרי שרוב התנועה תאומת, תוכלו להפעיל את האכיפה.
מידע נוסף והוראות מפורטות זמינים במסמכי התיעוד של Firebase App Check.