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

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

  • אתה רוצה להשתמש בספק אחר מאשר DeviceCheck או App Attest ב- 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. הוסף להיגיון נקודת הסיום שמעריך את נתוני האותנטיות. זהו ההיגיון המרכזי של ספק ה- Check Check המותאם אישית שלך, אותו תצטרך לכתוב בעצמך.

  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 דקות ל -7 ימים. בעת קביעת ערך זה, שים לב להנחיות הבאות:

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

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

הצעדים הבאים

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