با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
هنگام تأیید اینکه کاربر یک نسخه قانونی از برنامه شما را از فروشگاه Google Play خریداری یا دانلود کرده است، بهتر است بررسی تأیید مجوز را روی سروری که شما کنترل می‌کنید انجام دهید.
این راهنما یک فرآیند گام به گام را برای تکمیل تأیید مجوز سمت سرور ارائه می دهد و برخی از بهترین شیوه های مربوط به انجام این بررسی را ارائه می دهد.
نمای کلی فرآیند
شکل 1 نحوه انتقال اطلاعات بین برنامه، Google Play و سرور خصوصی شما را نشان می دهد:
شکل 1. جریان داده بین برنامه شما و Google Play، سپس بین برنامه و سرور خصوصی شما
برنامه شما درخواستی از Google Play می‌کند و می‌پرسد آیا یک کاربر خاص یک نسخه قانونی از برنامه شما را خریداری یا دانلود کرده است یا خیر.
Google Play با ارسال یک شی داده پاسخ ، یک شی از نوع ResponseData ، به برنامه شما پاسخ می دهد. این شیء یک قطعه اطلاعات امضا شده است که بیان می کند آیا کاربر یک نسخه قانونی از برنامه شما را خریداری کرده یا دانلود کرده است.
برنامه شما درخواستی را به سرور خصوصی که شما کنترل می‌کنید ارسال می‌کند و محتوای داده‌های پاسخ را تأیید می‌کند.
سرور با ارسال یک وضعیت به برنامه شما پاسخ می دهد، که نشان می دهد آیا کاربر واقعاً یک نسخه قانونی از برنامه شما را خریداری کرده یا دانلود کرده است. اگر سرور یک پیام "موفقیت" ارائه می دهد، پاسخ را تأیید کنید و سپس به کاربر اجازه دسترسی به منابعی را بدهید که نیاز به مجوز دارند.
از آنجا که داده‌های پاسخ توسط Google Play امضا می‌شوند، سپس در سرور شما بررسی می‌شوند، هیچ راهی برای تغییر شی در دستگاهی که برنامه شما را اجرا می‌کند وجود ندارد. اگر برنامه شما به سرور متکی است و منابع را فقط در اختیار کاربران قانونی قرار می دهد، برنامه شما به طور قابل ملاحظه ای در برابر کاربران غیرمجاز محافظت می شود.
بخش‌های زیر ملاحظات دیگری را ارائه می‌کنند که باید هنگام انجام تأیید مجوز سمت سرور در نظر داشته باشید.
محافظت در برابر حملات تکراری
پس از دریافت پاسخ از Google Play در مورد وضعیت مجوز کاربر، این امکان برای کاربر وجود دارد که داده‌های پاسخ را کپی کرده و چندین بار از آن استفاده کند، یا آن را به سایر کاربران بدهد تا بتوانند درخواست‌های خود را به سرور خصوصی برنامه شما جعل کنند. این نوع عمل به عنوان یک حمله تکراری شناخته می شود.
برای کاهش احتمال انجام موفقیت آمیز حملات تکراری توسط کاربران، اقدامات زیر را قبل از ارسال درخواست به سرور برنامه خود انجام دهید:
مهر زمانی موجود در داده‌های پاسخ را بررسی کنید و مطمئن شوید که Google Play اخیراً پاسخ را ایجاد کرده است.
برای کاهش تعداد دفعاتی که برنامه شما سعی می‌کند همان داده‌های پاسخ را به سرور برنامه شما ارسال کند، در درخواست سرور خود محدودیت نرخ را انجام دهید، مانند بازگشت نمایی.
قبل از تأیید محتویات داده‌های پاسخ Google Play در سرور خصوصی خود، یک درخواست اولیه و مبتنی بر احراز هویت از سرور خصوصی خود ارائه دهید. در این درخواست اول، اعتبار کاربری را به سرور خود ارسال کنید و سرور خود را با یک nonce یا عددی که فقط یک بار استفاده می شود پاسخ دهد. سپس می توانید این nonce را در درخواست بعدی خود به سرور خصوصی خود بگنجانید و اطلاعات تأیید مجوز را بخواهید. برای جزئیات در مورد نحوه انتخاب یک مقدار خوب برای nonce، بخش ایجاد یک مقدار nonce مناسب را ببینید.
یک مقدار nonce مناسب ایجاد کنید
برای ایجاد یک مقدار nonce که حدس زدن آن دشوار است از یکی از تکنیک های زیر استفاده کنید:
یک مقدار هش بر اساس شناسه کاربر ایجاد کنید.
یک مقدار تصادفی بر اساس هر کاربر ایجاد کنید. این مقدار تصادفی را در سرور برنامه خود به عنوان بخشی از ویژگی های یک کاربر خاص ذخیره کنید.
داده های پاسخ را از سرور خود تأیید کنید
هنگام بررسی داده های پاسخی که سرور برنامه شما به برنامه شما ارسال می کند، مطمئن شوید که پاسخ کتابخانه تأیید مجوز جعلی نباشد. امضای موجود در داده‌های پاسخ سرور برنامه را با مقایسه آن با کلیدی که برنامه شما در مرحله قبل از Google Play دریافت کرده بود، تأیید کنید.
همچنین لازم به یادآوری است که بلوک مخصوص کتابخانه تأیید مجوز (LVL) تنها بخشی است که امضا شده است. بنابراین، این تنها بخشی از داده های پاسخ سرور برنامه شما است که برنامه شما باید به آن اعتماد کند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
