الاستعانة بموفِّر لخدمة فحص التطبيقات المخصّص

App Check تتوفّر فيها ميزات مدمجة لخدمة العديد من مقدّمي الخدمات: DeviceCheck وApp Attest على منصات Apple وPlay Integrity على Android وreCAPTCHA Enterprise في تطبيقات الويب (نظرة عامة). إنّ هؤلاء مقدّمو خدمات معروفون جيدًا ويفترض أن يلبّوا احتياجات معظم المطوّرين. ومع ذلك، يمكنك أيضًا تنفيذ مقدّمي App Check مخصّصين. يكون استخدام موفِّر مخصّص ضروريًا في الحالات التالية:

  • إذا كنت تريد استخدام مزوِّد خدمة غير المزوِّدين المدمجين

  • إذا كنت تريد استخدام مقدّمي الخدمات المضمّنين بطرق غير متوافقة

  • إذا كنت تريد إثبات ملكية الأجهزة باستخدام منصات أخرى غير Apple وAndroid والويب على سبيل المثال، يمكنك إنشاء App Check مقدّمي خدمات لأنظمة التشغيل على أجهزة الكمبيوتر المكتبي أو أجهزة إنترنت الأشياء.

  • إذا كنت تريد تنفيذ أساليب التحقّق الخاصة بك على أيّ منصة

نظرة عامة

لتنفيذ مقدّم App Check مخصّص، تحتاج إلى بيئة تطوير خلفي آمنة يمكنها تشغيل Firebase Admin SDK Node.js. يمكن أن يكون ذلك Cloud Functions أو منصة حاويات مثل Cloud Run أو خادمك الخاص.

من هذه البيئة، ستقدّم خدمة متاحة على الشبكة تتلقّى App Check دليلاً على الأصالة من عملاء تطبيقك، وتُعرِض App Check رمزًا مميّزًا إذا اجتاز دليل الأصالة تقييم الأصالة. تعتمد المؤشرات المحدّدة التي تستخدمها كدليل على الأصالة على إما الموفّر التابع لجهة خارجية الذي تستخدمه، أو مؤشرات ابتكارك الخاص، إذا كنت تطبّق منطقًا مخصّصًا.

وعادةً ما تُعرِض هذه الخدمة كنقطة نهاية REST أو gRPC، ولكن هذه التفاصيل تعود إليك.

إنشاء نقطة نهاية الحصول على الرمز المميّز

  1. ثبِّت Admin SDK وأدخِل بياناته الأولية.

  2. أنشئ نقطة نهاية يمكن الوصول إليها من خلال الشبكة ويمكنها تلقّي بيانات الأصالة من عملائك. على سبيل المثال، باستخدام Cloud Functions:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
  // ...
});

  3. أضِف إلى منطق نقطة النهاية الذي يُقيّم بيانات الأصالة. هذا هو المنطق الأساسي لمقدّم App Check المخصّص، والذي عليك كتابته بنفسك.

  4. إذا تبيّن لك أنّ العميل موثوق به، استخدِم Admin SDK لإنشاء رمز App Check مميز وإرساله مع وقت انتهاء صلاحيته إلى العميل:

    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) لعناصر App Check التي يصدرها مزوّدك المخصّص من خلال تمرير عنصر AppCheckTokenOptions إلى createToken(). يمكنك ضبط وقت الاستبدال المؤقت على أي قيمة تتراوح بين 30 دقيقة و7 أيام. عند ضبط هذه القيمة، يجب الانتباه إلى المفاضلات التالية:

    • الأمان: توفّر فترات صلاحية قصيرة للذاكرة المؤقتة أمانًا أكبر، لأنّها تقلّل من المهلة التي يمكن فيها لمهاجمٍ إساءة استخدام رمز مميّز تم تسريبه أو اعتراضه.
    • الأداء: تعني مدد البقاء القصيرة أنّ تطبيقك سيُجري عملية إثبات الهوية بشكلٍ أكثر تكرارًا. بما أنّ عملية إثبات ملكية التطبيق تضيف وقت استجابة إلى طلبات الشبكة في كل مرة يتم فيها تنفيذها، يمكن أن تؤثّر مدة بقاء قصيرة في أداء تطبيقك.

    إنّ مدة البقاء التلقائية التي تبلغ ساعة واحدة مناسبة لمعظم التطبيقات.

الخطوات التالية

بعد تنفيذ منطق جهة الإصدار المخصّصة من جهة الخادم، تعرَّف على كيفية استخدامه من عملاء Apple وAndroid والويب.