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

تتضمّن 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);
      });
   

   ملاحظة: إذا واجهت خطأ في توقيع الرمز المميّز أثناء إنشاء رمز مميّز جديد، تأكَّد من أنّ حساب الخدمة لديه الأذونات المطلوبة. اطّلِع على دليل تحديد المشاكل وحلّها في Admin SDK.

   إذا تعذّر عليك التحقّق من صحة بيانات العميل، عليك عرض رسالة خطأ (على سبيل المثال، عرض رسالة الخطأ HTTP 403).

5. اختياري: اضبط مدة البقاء (TTL) لرموز App Check المميزة الصادرة عن مزوّدك المخصّص من خلال تمرير عنصر AppCheckTokenOptions إلى createToken(). يمكنك ضبط قيمة TTL على أي قيمة تتراوح بين 30 دقيقة و7 أيام. عند ضبط هذه القيمة، يجب الانتباه إلى المفاضلات التالية:

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

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

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

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