קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כשאתם בודקים שהמשתמש רכש או הוריד עותק חוקי של האפליקציה מחנות Google Play, מומלץ לבצע את בדיקת אימות הרישיון בשרת שבשליטתכם.
במדריך הזה מוסבר בהרחבה איך לבצע אימות רישיון בצד השרת, ומפורטות כמה שיטות מומלצות לביצוע הבדיקה הזו.
סקירה כללית של התהליך
באיור 1 מוצגת אופן העברת המידע בין האפליקציה, Google Play והשרת הפרטי:
איור 1. זרימת הנתונים בין האפליקציה ל-Google Play, ואז בין האפליקציה לשרתי הפרטיים שלכם
האפליקציה שולחת בקשה ל-Google Play כדי לבדוק אם משתמש מסוים קנה או הוריד עותק חוקי של האפליקציה.
בתגובה, Google Play שולחת לאפליקציה אובייקט של נתוני תגובה, אובייקט מסוג ResponseData. האובייקט הזה הוא פיסת מידע חתומה שמציינת אם המשתמש קנה או הוריד עותק חוקי של האפליקציה.
האפליקציה שולחת בקשה לשרת פרטי שבשליטתכם, ומאמתת את תוכן נתוני התגובה.
השרת מגיב על ידי שליחת סטטוס לאפליקציה, שמציין אם המשתמש אכן רכש או הוריד עותק חוקי של האפליקציה. אם השרת שולח את ההודעה 'success', מאמתים את התגובה ואז מעניקים למשתמש גישה למשאבים שדורשים רישיון.
מכיוון שנתוני התגובה נחתמים על ידי Google Play ולאחר מכן נבדקים בשרת, אין דרך לשנות את האובייקט במכשיר שבו פועלת האפליקציה. אם האפליקציה מסתמכת על השרת ומאפשרת למשאבים להיות זמינים רק למשתמשים מורשים, האפליקציה מוגנת בצורה משמעותית יותר מפני משתמשים לא מורשים.
בסעיפים הבאים מפורטות נקודות נוספות שכדאי לזכור כשמבצעים אימות רישיון בצד השרת.
הגנה מפני התקפות שחזור
אחרי קבלת תשובה מ-Google Play לגבי סטטוס הרישיון של המשתמש, המשתמש יכול להעתיק את נתוני התשובה ולהשתמש בהם כמה פעמים, או לתת אותם למשתמשים אחרים שיכולים לזייף בקשות משלהם לשרת הפרטי של האפליקציה. פעולה כזו נקראת מתקפת שליחה מחדש.
כדי לצמצם את הסיכוי שמשתמשים יצליחו לבצע התקפות שחזור, כדאי לבצע את הפעולות הבאות לפני שליחת בקשה לשרת של האפליקציה:
בודקים את חותמת הזמן שכלולה בנתוני התגובה, ומוודאים ש-Google Play יצרה את התגובה לאחרונה.
כדאי להגביל את הקצב של בקשות השרת, למשל באמצעות השהיה מעריכית, כדי לצמצם את מספר הפעמים שהאפליקציה תנסה לשלוח את אותם נתוני תגובה לשרת של האפליקציה.
לפני שתאמתו את תוכן נתוני התגובה של Google Play בשרת הפרטי, עליכם לשלוח בקשה ראשונית מבוססת-אימות לשרת הפרטי. בבקשה הראשונה, שולחים את פרטי הכניסה של המשתמש לשרת, והשרת משיב בnonce, או מספר שמשמש רק פעם אחת. לאחר מכן תוכלו לכלול את המזהה החד-פעמי הזה בבקשה הבאה לשרת הפרטי, שבה תבקשו לקבל את נתוני האימות של הרישיון. פרטים על בחירת ערך טוב למזהה החד-פעמי מופיעים בקטע יצירת ערך nonce מתאים.
יצירת ערך nonce מתאים
אפשר להשתמש באחת מהשיטות הבאות כדי ליצור ערך nonce שקשה לנחש:
יצירת ערך גיבוב על סמך המזהה של המשתמש.
יצירת ערך אקראי לכל משתמש. שומרים את הערך האקראי הזה בשרת של האפליקציה כחלק מהמאפיינים של משתמש נתון.
אימות נתוני התגובה מהשרת
כשבודקים את נתוני התשובה שהשרת של האפליקציה שולח לאפליקציה, חשוב לוודא שהתגובה של ספריית אימות הרישיון לא מזויפת. מאמתים את החתימה שכלולה בנתוני התגובה של שרת האפליקציה על ידי השוואה למפתח שהאפליקציה קיבלה מ-Google Play בשלב קודם.
חשוב גם לזכור שהבלוק הספציפי ל-License Verification Library (LVL) הוא החלק היחיד שנחתם. לכן, זהו החלק היחיד בנתוני התגובה של שרת האפליקציה שאפליקצייתכם צריכה לסמוך עליו.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","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-27 (שעון UTC)."],[],[],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."]]
