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

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 إذا اجتاز إثبات المصداقية تقييمك. وتعتمد المؤشرات المحدَّدة التي تستخدمها كدليل على الموثوقية على مزوّد الجهة الخارجية الذي تستخدمه أو مؤشرات اختراعك الخاص في حال تطبيق منطق مخصّص.

وعادةً ما تُعرِض هذه الخدمة كنقطة نهاية 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 أيام. عند ضبط هذه القيمة، يجب الانتباه إلى المُفاضلات التالية:

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

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

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

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