تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتضمّن 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، ولكن يعود إليك تحديد هذه التفاصيل.
أنشئ نقطة نهاية يمكن الوصول إليها عبر الشبكة ويمكنها تلقّي بيانات المصادقة من عملائك. على سبيل المثال، باستخدام Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckTokenexports.fetchAppCheckToken=functions.https.onRequest((request,response)=>{// ...});
أضِف إلى منطق نقطة النهاية ما يقيّم صحة البيانات. هذا هو المنطق الأساسي لموفّر App Check المخصّص، والذي عليك كتابته بنفسك.
إذا تبيّن لك أنّ العميل موثوق به، استخدِم Admin SDK لإنشاء رمز مميز App Check وإرجاعه مع وقت انتهاء صلاحيته إلى العميل:
constadmin=require('firebase-admin');admin.initializeApp();// ...admin.appCheck().createToken(appId).then(function(appCheckToken){// Token expires in an hour.constexpiresAt=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).
اختياري: اضبط مدة البقاء (TTL) لرموز App Check المميزة الصادرة عن مزوّدك المخصّص من خلال تمرير عنصر AppCheckTokenOptions إلى createToken(). يمكنك ضبط قيمة TTL على أي قيمة تتراوح بين 30 دقيقة و7 أيام. عند ضبط هذه القيمة، يجب الانتباه إلى المفاضلات التالية:
الأمان: توفّر قيم TTL الأقصر مستوى أمان أعلى، لأنّها تقلّل من الفترة الزمنية التي يمكن للمهاجم إساءة استخدام الرمز المميز المسروق أو الذي تم اعتراضه خلالها.
الأداء: يعني استخدام مدة بقاء (TTL) أقصر أنّ تطبيقك سيجري عملية التصديق بشكل متكرّر أكثر. بما أنّ عملية إثبات صحة التطبيق تضيف وقت استجابة إلى طلبات الشبكة في كل مرة يتم تنفيذها، يمكن أن تؤثّر مدة البقاء القصيرة في أداء تطبيقك.
إنّ مدة البقاء التلقائية البالغة ساعة واحدة مناسبة لمعظم التطبيقات.
الخطوات التالية
بعد تنفيذ منطق الخادم الخاص بموفّر الخدمة المخصّص، تعرَّف على كيفية استخدامه من خلال عملاء Apple وAndroid والويب.
تاريخ التعديل الأخير: 2025-08-23 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-23 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]
