יישם ספק בדיקת אפליקציות מותאם אישית

בדקו שאפליקצית תמיכה מובנית עבור מספר ספקים: DeviceCheck על iOS, אנדרואיד SafetyNet על, או v3 reCAPTCHA באפליקציות אינטרנט ( סקירה ). מדובר בספקים מובנים שצריכים לענות על הצרכים של רוב המפתחים. תוכל, עם זאת, גם ליישם ספקי בדיקת אפליקציות מותאמים אישית משלך. שימוש בספק מותאם אישית הכרחי כאשר:

  • אתה רוצה להשתמש בספק שאינו DeviceCheck ב- iOS, SafetyNet באנדרואיד, או reCAPTCHA באפליקציות אינטרנט.

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

  • אתה רוצה ליישם טכניקות אימות משלך בכל פלטפורמה.

סקירה כללית

כדי ליישם ספקית בדיקת יישום מותאם אישית, אתה צריך סביבה backend מאובטח שיכול להפעיל את Node.js SDK של ניהול Firebase . זה יכול להיות פונקציות ענן, רציף מכולות כגון ענן הפעלה , או שרת משלך.

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

בדרך כלל אתה חושף שירות זה כנקודת קצה של REST או של gRPC, אך פרט זה תלוי בך.

צור את נקודת הסיום של רכישת אסימון

  1. התקן לאתחל SDK של מנהל המערכת .

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

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => {
      // ...
    });
    
  3. הוסף לוגיקת הקצה שמעריכה את נתוני האותנטיות. זהו ההיגיון המרכזי של ספק בדיקת האפליקציות המותאם אישית שלך, אותו תצטרך לכתוב בעצמך.

  4. אם אתה קובע שהלקוח יהיה אותנטי, השתמש ב- SDK של מנהל המערכת כדי להטביע אסימון של בדיקת אפליקציות ולהחזיר אותו וזמן התפוגה שלו ללקוח:

    const admin = require('firebase-admin');
    admin.initializeApp();
    
    // ...
    
    admin.appCheck().createToken(appId)
        .then(function (appCheckToken) {
          // Token expires in an hour.
          const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;
    
          // Return appCheckToken and expiresAt to the client.
        })
       .catch(function (err) {
         console.error('Unable to create App Check token.');
         console.error(err);
       });
    

    אם אינך יכול לאמת את האותנטיות של הלקוח, החזר שגיאה (לדוגמה, החזיר שגיאת HTTP 403).

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

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

    ברירת המחדל של TTL לשעה הינה סבירה עבור רוב האפליקציות.

הצעדים הבאים

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