تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
عند التأكّد من أنّ المستخدم قد اشترى أو نزّل نسخة صالحة من تطبيقك من "متجر Google Play"، من الأفضل إجراء فحص التحقّق من الترخيص على خادم تتحكَّم فيه.
يقدم هذا الدليل عملية خطوة بخطوة لإكمال التحقق من الترخيص من جهة الخادم ويقدم بعض أفضل الممارسات المتعلقة بإجراء هذا الفحص.
نظرة عامة على العملية
يوضّح الشكل 1 كيفية نقل المعلومات بين تطبيقك وGoogle Play والخادم الخاص:
الشكل 1. تدفق البيانات بين تطبيقك وGoogle Play، ثم بين تطبيقك والخادم الخاص
يرسل تطبيقك طلبًا إلى Google Play للاستعلام عما إذا كان مستخدم معيّن قد اشترى أو نزّل نسخة صالحة من تطبيقك.
ويردّ Google Play على التطبيق من خلال إرسال كائن بيانات الاستجابة، وهو كائن من النوع ResponseData، إلى تطبيقك. وهذا الكائن عبارة عن معلومة موقعة توضّح ما إذا كان المستخدم قد اشترى أو نزّل نسخةً مشروعة من تطبيقك.
يرسل تطبيقك طلبًا إلى خادم خاص يمكنك التحكّم فيه، ويتحقّق من
محتوى بيانات الاستجابة.
يستجيب الخادم بإرسال حالة إلى تطبيقك للإشارة إلى ما إذا كان المستخدم قد اشترى أو نزّل نسخة صالحة من تطبيقك. وإذا كان الخادم يقدم رسالة "تم بنجاح"، يجب التحقق من الرد، ثم منح المستخدم إمكانية الوصول إلى الموارد التي تتطلب ترخيصًا.
بما أنّ بيانات الاستجابة يتم توقيعها من خلال Google Play ثم التحقّق منها في
الخادم الخاص بك، لا تتوفّر طريقة لتعديل العنصر في الجهاز الذي يشغّل تطبيقك. فإذا
كان تطبيقك يعتمد على الخادم ولا يوفّر الموارد إلا للمستخدمين الشرعيين، تتم زيادة حماية تطبيقك من المستخدمين غير المصرّح لهم.
تقدم الأقسام التالية اعتبارات إضافية يجب وضعها في الاعتبار عند إجراء التحقق من الترخيص من جهة الخادم.
الحماية من هجمات إعادة اللعب
وبعد تلقّي رد من Google Play بشأن حالة ترخيص المستخدم،
من الممكن أن ينسخ بيانات الاستجابة ويستخدمها عدة مرات،
أو يمنحها للمستخدمين الآخرين الذين يمكنهم حينئذٍ تزييف طلباتهم الخاصة إلى
الخادم الخاص لتطبيقك. ويُعرف هذا النوع من الإجراءات باسم هجوم إعادة التشغيل.
للحد من احتمالية تنفيذ المستخدمين لهجمات إعادة تشغيل بنجاح، اتّخِذ الإجراءات التالية قبل إرسال طلب إلى خادم تطبيقك:
تحقَّق من الطابع الزمني الذي يظهر في بيانات الردّ للتأكّد من أنّ
Google Play هو من أنشأ الردّ مؤخرًا.
يمكنك تحديد معدّل الوصول إلى طلب الخادم، مثل التراجع الأسي،
لتقليل عدد المرات التي يحاول فيها تطبيقك إرسال بيانات الاستجابة نفسها
إلى خادم التطبيق.
قبل التحقق من محتوى بيانات استجابة Google Play على خادمك الخاص، عليك إرسال طلب مبدئي يستند إلى المصادقة إلى خادمك الخاص. في هذا الطلب الأول، أرسِل بيانات اعتماد المستخدم إلى خادمك واطلب من الخادم بعد ذلك الاستجابة برقم غير مميّز أو برقم يُستخدم مرة واحدة فقط. يمكنك بعد ذلك تضمين هذا الرقم في طلبك التالي إلى خادمك الخاص، وطلب بيانات التحقق من الترخيص. للاطّلاع على تفاصيل حول كيفية اختيار قيمة جيدة للرقم، يُرجى مراجعة القسم إنشاء قيمة خاصة مناسبة.
إنشاء قيمة nonce مناسبة
استخدِم أحد الأساليب التالية لإنشاء قيمة خاصة يصعب تخمينها:
إنشاء قيمة تجزئة استنادًا إلى رقم تعريف المستخدم
يمكنك إنشاء قيمة عشوائية على أساس كل مستخدم. قم بتخزين هذه القيمة العشوائية على خادم
تطبيقك كجزء من سمات مستخدم معين.
التحقُّق من بيانات الاستجابة من الخادم
عند مراجعة بيانات الاستجابة التي يرسلها خادم التطبيق إلى تطبيقك، تأكَّد من أنّ استجابة "مكتبة التحقق من الترخيص" ليست مزيفة. تحقَّق من
التوقيع المضمّن في بيانات استجابة خادم التطبيق من خلال مقارنته
بالمفتاح الذي تلقّاه تطبيقك من Google Play في خطوة سابقة.
تجدر الإشارة أيضًا إلى أنّ الحظر الخاص بمكتبة التحقّق من
الترخيص (LVL) هو الجزء الوحيد الذي يتم توقيعه. ولذلك، فإنه الجزء الوحيد من بيانات استجابة خادم التطبيق
الذي يجب أن يثق به تطبيقك.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Adding Server-Side License Verification to Your App\n\nWhen verifying that the user has purchased or downloaded a legitimate copy of\nyour app from the Google Play Store, it's best to perform the license\nverification check on a server that you control.\n\nThis guide presents a step-by-step process for completing server-side license\nverification and presents some best practices related to performing this check.\n\nProcess overview\n----------------\n\nFigure 1 shows how information is transferred between your app, Google Play, and\nyour private server: \n**Figure 1.** Flow of data between your app and Google Play, then between your app and your private server\n\n1. Your app makes a request to Google Play, inquiring about whether a particular user has purchased or downloaded a legitimate copy of your app.\n2. Google Play responds by sending a *response data object* , an object of type [`ResponseData`](/google/play/licensing/licensing-reference#lvl-summary), to your app. This object is a signed piece of information that states whether the user has purchased or downloaded a legitimate copy of your app.\n3. Your app makes a request to a private server that you control, verifying the contents of the response data.\n4. The server responds by sending a status to your app, indicating whether the user has indeed purchased or downloaded a legitimate copy of your app. If the server provides a \"success\" message, [verify the\n response](#verify-app-server-response) and then grant the user access to the resources that require a license.\n\nBecause the response data is signed by Google Play, then checked on your\nserver, there's no way to modify the object on the device running your app. If\nyour app relies on the server and makes resources available only to legitimate\nusers, your app is substantially more protected against unauthorized users.\n\nThe following sections provide additional considerations to keep in mind when\nperforming server-side license verification.\n\nSafeguard against replay attacks\n--------------------------------\n\nAfter receiving a response from Google Play regarding the user's license status,\nit's possible for the user to copy the response data and use it multiple times,\nor give it to other users who could then forge their own requests to your app's\nprivate server. This sort of action is known as a *replay attack*.\n\nTo reduce the likelihood of users performing replay attacks successfully, take\nthe following measures before sending a request to your app's server:\n\n- Check the timestamp that's included in the response data, making sure that\n Google Play generated the response recently.\n\n | **Note:** You can increase the allowed difference between the response data's timestamp and the current time based on how long users should be able to interact with license-bound resources after they deactivate their license.\n- Perform rate-limiting on your server request, such as exponential backoff, to\n reduce the number of times that your app attempts to send the same response data\n to your app's server.\n\n | **Caution:** To preserve a good user experience in cases where a user interacts with your app on a variety of devices, be careful if you add rate-limiting based on number of devices.\n- Before verifying the contents of Google Play's response data on your private\n server, make an initial, authentication-based request to your private server. In\n this first request, send user credentials to your server, and have your server\n then respond with a *nonce* , or a number that is used only once. You can then\n include this nonce in your next request to your private server, asking for\n license verification data. For details on how to choose a good value for the\n nonce, see the [generate a suitable nonce value](#generate-nonce) section.\n\n | **Note:** Include a user ID field in both the nonce request and the license verification request. Your app's server can then compare the fields' values from the two requests and make sure they match.\n\n### Generate a suitable nonce value\n\nUse one of the following techniques to create a nonce value that's difficult to\nguess:\n\n- Generate a hash value based on the user's ID.\n- Generate a random value on a per-user basis. Store this random value on your app's server as part of a given user's attributes.\n\nVerify response data from your server\n-------------------------------------\n\nWhen reviewing response data that your app's server sends to your app, make sure\nthat the License Verification Library response isn't forged. Verify the\nsignature that's included in the app server's response data by comparing it\nwith the key that your app received from Google Play in a previous step.\n\nIt's also worth remembering that the block specific to the License Verification\nLibrary (LVL) is the only part that's signed. Therefore, it's the only part of\nyour app server's response data that your app should trust."]]
