सर्वर-साइड से की जाने वाली पुष्टि के कॉलबैक, यूआरएल के ऐसे अनुरोध होते हैं जिनमें Google, क्वेरी पैरामीटर जोड़ता है. Google, इन अनुरोधों को किसी बाहरी सिस्टम को भेजता है, ताकि उसे यह सूचना दी जा सके कि इनाम वाले या इनाम वाले इंटरस्टीशियल विज्ञापन के साथ इंटरैक्ट करने पर, उपयोगकर्ता को इनाम दिया जाना चाहिए. इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक, उपयोगकर्ताओं को इनाम देने के लिए, क्लाइंट-साइड के कॉलबैक की स्पूफ़िंग से सुरक्षा की एक और लेयर उपलब्ध कराते हैं.
इस गाइड में, Tink Java Apps की तीसरे पक्ष की क्रिप्टोग्राफ़िक लाइब्रेरी का इस्तेमाल करके, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने का तरीका बताया गया है. इससे यह पक्का किया जा सकता है कि कॉलबैक में मौजूद क्वेरी पैरामीटर, सही वैल्यू हों. हालांकि, इस गाइड में Tink का इस्तेमाल किया गया है, लेकिन आपके पास ECDSA के साथ काम करने वाली किसी भी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल करने का विकल्प है. AdMob यूज़र इंटरफ़ेस (यूआई) में मौजूद testing tool की मदद से, अपने सर्वर की जांच भी की जा सकती है.
Java spring-boot का इस्तेमाल करके, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक का उदाहरण देखें.
ज़रूरी शर्तें
- अपनी विज्ञापन यूनिट पर, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) की सुविधा चालू करें.
Tink Java Apps लाइब्रेरी से RewardedAdsVerifier का इस्तेमाल करना
Tink Java Apps की GitHub रिपॉज़िटरी
में,
RewardedAdsVerifier
हेल्पर क्लास शामिल है. इससे, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए ज़रूरी कोड कम हो जाता है.
इस क्लास का इस्तेमाल करके, यहां दिए गए कोड की मदद से कॉलबैक यूआरएल की पुष्टि की जा सकती है.
RewardedAdsVerifier verifier = new RewardedAdsVerifier.Builder()
.fetchVerifyingPublicKeysWith(
RewardedAdsVerifier.KEYS_DOWNLOADER_INSTANCE_PROD)
.build();
String rewardUrl = ...;
verifier.verify(rewardUrl);
अगर verify() तरीका, कोई अपवाद दिखाए बिना काम करता है, तो कॉलबैक यूआरएल की पुष्टि हो गई है. उपयोगकर्ताओं को इनाम देना
सेक्शन में, इस बारे में सबसे सही तरीके बताए गए हैं कि उपयोगकर्ताओं को कब इनाम दिया जाना चाहिए. इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए, इस क्लास की ओर से किए गए चरणों के बारे में जानने के लिए, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) की मैन्युअल तरीके से पुष्टि करना सेक्शन पढ़ें.
सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक के पैरामीटर
सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक में, क्वेरी पैरामीटर शामिल होते हैं. इनमें इनाम वाले विज्ञापन के साथ इंटरैक्शन की जानकारी होती है. पैरामीटर के नाम, ब्यौरे, और उदाहरण के तौर पर दी गई वैल्यू यहां दी गई हैं. पैरामीटर, वर्णमाला के क्रम में भेजे जाते हैं.
| पैरामीटर का नाम | ब्यौरा | उदाहरण के तौर पर दी गई वैल्यू |
|---|---|---|
| ad_network | विज्ञापन सोर्स का आइडेंटिफ़ायर. यह आइडेंटिफ़ायर, उस विज्ञापन सोर्स के लिए होता है जिसने यह विज्ञापन दिखाया है. आईडी वैल्यू के हिसाब से विज्ञापन सोर्स के नाम, विज्ञापन सोर्स आइडेंटिफ़ायर सेक्शन में दिए गए हैं. | 1953547073528090325 |
| ad_unit | AdMob विज्ञापन यूनिट का आईडी. इसका इस्तेमाल, इनाम वाले विज्ञापन का अनुरोध करने के लिए किया गया था. | 2747237135 |
| custom_data | कस्टम डेटा स्ट्रिंग, जिसे
setCustomData की मदद से उपलब्ध कराया गया है.
अगर ऐप्लिकेशन, कस्टम डेटा स्ट्रिंग उपलब्ध नहीं कराता है, तो यह क्वेरी पैरामीटर वैल्यू, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक में मौजूद नहीं होगी. |
SAMPLE_CUSTOM_DATA_STRING |
| key_id | सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी. यह वैल्यू, AdMob की सर्वर कुंजी से मिली सार्वजनिक कुंजी से मैप होती है. | 1234567890 |
| reward_amount | इनाम की रकम, जैसा कि विज्ञापन यूनिट की सेटिंग में बताया गया है. | 5 |
| reward_item | इनाम का आइटम, जैसा कि विज्ञापन यूनिट की सेटिंग में बताया गया है. | coins |
| signature | AdMob से जनरेट किया गया, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक का सिग्नेचर. | MEUCIQCLJS_s4ia_sN06HqzeW7Wc3nhZi4RlW3qV0oO-6AIYdQIgGJEh-rzKreO-paNDbSCzWGMtmgJHYYW9k2_icM9LFMY |
| timestamp | टाइमस्टैंप, जो यह बताता है कि उपयोगकर्ता को कब इनाम दिया गया था. यह टाइमस्टैंप, Epoch टाइम के तौर पर मिलीसेकंड में होता है. | 1507770365237823 |
| transaction_id | AdMob से जनरेट किए गए, इनाम देने के हर इवेंट के लिए, हेक्स में एनकोड किया गया यूनीक आइडेंटिफ़ायर. | 18fa792de1bca816048293fc71035638 |
| user_id | उपयोगकर्ता का आइडेंटिफ़ायर, जिसे
setUserId की मदद से उपलब्ध कराया गया है.
अगर ऐप्लिकेशन, उपयोगकर्ता का आइडेंटिफ़ायर उपलब्ध नहीं कराता है, तो यह क्वेरी पैरामीटर, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक में मौजूद नहीं होगा. |
1234567 |
विज्ञापन सोर्स के आइडेंटिफ़ायर
विज्ञापन सोर्स के नाम और आईडी
| विज्ञापन सोर्स का नाम | विज्ञापन सोर्स का आईडी |
|---|---|
| Ad Generation (बिडिंग) | 1477265452970951479 |
| AdColony | 15586990674969969776 |
| AdColony (बिडिंग) | 6895345910719072481 |
| AdFalcon | 3528208921554210682 |
| AdMob नेटवर्क | 5450213213286189855 |
| AdMob नेटवर्क वॉटरफ़ॉल | 1215381445328257950 |
| Applovin | 1063618907739174004 |
| Applovin (बिडिंग) | 1328079684332308356 |
| Chartboost | 2873236629771172317 |
| Chocolate Platform (बिडिंग) | 6432849193975106527 |
| कस्टम इवेंट | 18351550913290782395 |
| DT Exchange* * 21 सितंबर, 2022 से पहले, इस नेटवर्क को "Fyber Marketplace" कहा जाता था. | 2179455223494392917 |
| Equativ (बिडिंग)* * 12 जनवरी, 2023 से पहले, इस नेटवर्क को "Smart Adserver" कहा जाता था. | 5970199210771591442 |
| Fluct (बिडिंग) | 8419777862490735710 |
| Flurry | 3376427960656545613 |
| Fyber* * इस विज्ञापन सोर्स का इस्तेमाल, पुराने डेटा की रिपोर्टिंग के लिए किया जाता है. | 4839637394546996422 |
| i-mobile | 5208827440166355534 |
| Improve Digital (बिडिंग) | 159382223051638006 |
| Index Exchange (बिडिंग) | 4100650709078789802 |
| InMobi | 7681903010231960328 |
| InMobi (बिडिंग) | 6325663098072678541 |
| InMobi Exchange (बिडिंग) | 5264320421916134407 |
| IronSource | 6925240245545091930 |
| ironSource Ads (बिडिंग) | 1643326773739866623 |
| Leadbolt | 2899150749497968595 |
| Liftoff Monetize* * 30 जनवरी, 2023 से पहले, इस नेटवर्क को "Vungle" कहा जाता था. | 1953547073528090325 |
| Liftoff Monetize (बिडिंग)* * 30 जनवरी, 2023 से पहले, इस नेटवर्क को "Vungle (बिडिंग)" कहा जाता था. | 4692500501762622185 |
| LG U+AD | 18298738678491729107 |
| LINE Ads Network | 3025503711505004547 |
| Magnite DV+ (बिडिंग) | 3993193775968767067 |
| maio | 7505118203095108657 |
| maio (बिडिंग) | 1343336733822567166 |
| Media.net (बिडिंग) | 2127936450554446159 |
| मीडिएटेड हाउस विज्ञापन | 6060308706800320801 |
| Meta Audience Network* * 6 जून, 2022 से पहले, इस नेटवर्क को "Facebook Audience Network" कहा जाता था. | 10568273599589928883 |
| Meta Audience Network (बिडिंग)* * 6 जून, 2022 से पहले, इस नेटवर्क को "Facebook Audience Network (बिडिंग)" कहा जाता था. | 11198165126854996598 |
| Mintegral | 1357746574408896200 |
| Mintegral (बिडिंग) | 6250601289653372374 |
| MobFox (बिडिंग) | 3086513548163922365 |
| MoPub (अब सेवा में नहीं है) | 10872986198578383917 |
| myTarget | 8450873672465271579 |
| Nend | 9383070032774777750 |
| Nexxen (बिडिंग)* * 1 मई, 2024 से पहले, इस नेटवर्क को "UnrulyX" कहा जाता था. | 2831998725945605450 |
| OneTag Exchange (बिडिंग) | 4873891452523427499 |
| OpenX (बिडिंग) | 4918705482605678398 |
| Pangle | 4069896914521993236 |
| Pangle (बिडिंग) | 3525379893916449117 |
| PubMatic (बिडिंग) | 3841544486172445473 |
| रिज़र्वेशन कैंपेन | 7068401028668408324 |
| SK planet | 734341340207269415 |
| Sharethrough (बिडिंग) | 5247944089976324188 |
| Smaato (बिडिंग) | 3362360112145450544 |
| Sonobi (बिडिंग) | 3270984106996027150 |
| Tapjoy | 7295217276740746030 |
| Tapjoy (बिडिंग) | 4692500501762622178 |
| Tencent GDT | 7007906637038700218 |
| TripleLift (बिडिंग) | 8332676245392738510 |
| Unity Ads | 4970775877303683148 |
| Unity Ads (बिडिंग) | 7069338991535737586 |
| Verve Group (बिडिंग) | 5013176581647059185 |
| Vpon | 1940957084538325905 |
| Yieldmo (बिडिंग) | 4193081836471107579 |
| YieldOne (बिडिंग) | 3154533971590234104 |
| Zucks | 5506531810221735863 |
उपयोगकर्ता को इनाम देना
उपयोगकर्ता को इनाम कब देना है, यह तय करते समय, उपयोगकर्ता अनुभव और इनाम की पुष्टि के बीच संतुलन बनाए रखना ज़रूरी है. सर्वर-साइड के कॉलबैक को बाहरी सिस्टम तक पहुंचने में देरी हो सकती है. इसलिए, हमारा सुझाव है कि उपयोगकर्ता को तुरंत इनाम देने के लिए, क्लाइंट-साइड के कॉलबैक का इस्तेमाल करें. साथ ही, सर्वर-साइड के कॉलबैक मिलने पर, सभी इनामों की पुष्टि करें. इस तरीके से, उपयोगकर्ताओं को बेहतर अनुभव मिलता है. साथ ही, यह पक्का किया जा सकता है कि दिए गए इनाम मान्य हों.
हालांकि, ऐसे ऐप्लिकेशन जिनके लिए इनाम की वैधता ज़रूरी है (उदाहरण के लिए, इनाम से आपके ऐप्लिकेशन की इन-गेम अर्थव्यवस्था पर असर पड़ता है) और इनाम देने में देरी हो सकती है, तो पुष्टि किए गए सर्वर-साइड के कॉलबैक का इंतज़ार करना सबसे सही तरीका हो सकता है.
कस्टम डेटा
जिन ऐप्लिकेशन को सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक में ज़्यादा डेटा की ज़रूरत होती है उन्हें इनाम वाले विज्ञापनों की कस्टम डेटा सुविधा का इस्तेमाल करना चाहिए. इनाम वाले विज्ञापन के ऑब्जेक्ट पर सेट की गई कोई भी स्ट्रिंग वैल्यू, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक के custom_data क्वेरी पैरामीटर को पास की जाती है. अगर कस्टम डेटा की कोई वैल्यू सेट नहीं की जाती है, तो custom_data क्वेरी पैरामीटर वैल्यू, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक में मौजूद नहीं होगी.
यहां दिए गए उदाहरण में, इनाम वाला विज्ञापन लोड होने के बाद, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के विकल्प सेट किए गए हैं:
Java
RewardedAd.load(MainActivity.this, "AD_UNIT_ID", new AdRequest.Builder().build(), new RewardedAdLoadCallback() { @Override public void onAdLoaded(RewardedAd ad) { Log.d(TAG, "Ad was loaded."); rewardedAd = ad; ServerSideVerificationOptions options = new ServerSideVerificationOptions .Builder() .setCustomData("SAMPLE_CUSTOM_DATA_STRING") .build(); rewardedAd.setServerSideVerificationOptions(options); } @Override public void onAdFailedToLoad(LoadAdError loadAdError) { Log.d(TAG, loadAdError.toString()); rewardedAd = null; } });
Kotlin
RewardedAd.load(this, "AD_UNIT_ID", AdRequest.Builder().build(), object : RewardedAdLoadCallback() { override fun onAdLoaded(ad: RewardedAd) { Log.d(TAG, "Ad was loaded.") rewardedInterstitialAd = ad val options = ServerSideVerificationOptions.Builder() .setCustomData("SAMPLE_CUSTOM_DATA_STRING") .build() rewardedAd.setServerSideVerificationOptions(options) } override fun onAdFailedToLoad(adError: LoadAdError) { Log.d(TAG, adError?.toString()) rewardedAd = null } })
अगर आपको इनाम के लिए कस्टम स्ट्रिंग सेट करनी है, तो आपको विज्ञापन दिखाने से पहले ऐसा करना होगा.
इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) की मैन्युअल तरीके से पुष्टि करना
इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) की पुष्टि करने के लिए, RewardedAdsVerifier क्लास की ओर से किए गए चरणों के बारे में यहां बताया गया है. हालांकि, शामिल किए गए कोड स्निपेट Java में हैं और
इनमें Tink की तीसरे पक्ष की लाइब्रेरी का इस्तेमाल किया गया है. फिर भी, इन चरणों को अपनी पसंद की भाषा में लागू किया जा सकता है. इसके लिए, ECDSA के साथ काम करने वाली किसी भी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल किया जा सकता है.
ECDSA.
सार्वजनिक कुंजियां फ़ेच करना
इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए, आपको AdMob से मिली सार्वजनिक कुंजी की ज़रूरत होगी.
इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए इस्तेमाल की जाने वाली सार्वजनिक कुंजियों की सूची, AdMob की सर्वर कुंजी से फ़ेच की जा सकती है. सार्वजनिक कुंजियों की सूची, JSON फ़ॉर्मैट में उपलब्ध कराई जाती है. इसका फ़ॉर्मैट, यहां दिए गए उदाहरण जैसा होता है:
{
"keys": [
{
keyId: 1916455855,
pem: "-----BEGIN PUBLIC KEY-----\nMF...YTPcw==\n-----END PUBLIC KEY-----"
base64: "MFkwEwYHKoZIzj0CAQYI...ltS4nzc9yjmhgVQOlmSS6unqvN9t8sqajRTPcw=="
},
{
keyId: 3901585526,
pem: "-----BEGIN PUBLIC KEY-----\nMF...aDUsw==\n-----END PUBLIC KEY-----"
base64: "MFYwEAYHKoZIzj0CAQYF...4akdWbWDCUrMMGIV27/3/e7UuKSEonjGvaDUsw=="
},
],
}
सार्वजनिक कुंजियां पाने के लिए, AdMob की सर्वर कुंजी से कनेक्ट करें और कुंजियां डाउनलोड करें. यहां दिया गया कोड, इस टास्क को पूरा करता है और कुंजियों के JSON फ़ॉर्मैट को data वैरिएबल में सेव करता है.
String url = ...;
NetHttpTransport httpTransport = new NetHttpTransport.Builder().build();
HttpRequest httpRequest =
httpTransport.createRequestFactory().buildGetRequest(new GenericUrl(url));
HttpResponse httpResponse = httpRequest.execute();
if (httpResponse.getStatusCode() != HttpStatusCodes.STATUS_CODE_OK) {
throw new IOException("Unexpected status code = " + httpResponse.getStatusCode());
}
String data;
InputStream contentStream = httpResponse.getContent();
try {
InputStreamReader reader = new InputStreamReader(contentStream, UTF_8);
data = readerToString(reader);
} finally {
contentStream.close();
}
ध्यान दें कि सार्वजनिक कुंजियां, समय-समय पर रोटेट की जाती हैं. आपको आने वाले रोटेशन के बारे में बताने के लिए एक ईमेल मिलेगा. अगर सार्वजनिक कुंजियों को कैश किया जा रहा है, तो आपको यह ईमेल मिलने पर, कुंजियों को अपडेट करना चाहिए.
सार्वजनिक कुंजियां फ़ेच करने के बाद, उन्हें पार्स करना होगा. parsePublicKeysJson का यहां दिया गया तरीका, इनपुट के तौर पर JSON स्ट्रिंग लेता है. जैसे, ऊपर दिया गया उदाहरण. साथ ही, यह key_id वैल्यू से सार्वजनिक कुंजियों की मैपिंग बनाता है. इन कुंजियों को, Tink लाइब्रेरी से ECPublicKey ऑब्जेक्ट के तौर पर एनकैप्सुलेट किया जाता है.
private static Map<Integer, ECPublicKey> parsePublicKeysJson(String publicKeysJson)
throws GeneralSecurityException {
Map<Integer, ECPublicKey> publicKeys = new HashMap<>();
try {
JSONArray keys = new JSONObject(publicKeysJson).getJSONArray("keys");
for (int i = 0; i < keys.length(); i++) {
JSONObject key = keys.getJSONObject(i);
publicKeys.put(
key.getInt("keyId"),
EllipticCurves.getEcPublicKey(Base64.decode(key.getString("base64"))));
}
} catch (JSONException e) {
throw new GeneralSecurityException("failed to extract trusted signing public keys", e);
}
if (publicKeys.isEmpty()) {
throw new GeneralSecurityException("No trusted keys are available.");
}
return publicKeys;
}
पुष्टि किया जाने वाला कॉन्टेंट पाना
इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक के आखिरी दो क्वेरी पैरामीटर हमेशा signature
और key_id, होते हैं. इनका क्रम यही होता है. बाकी क्वेरी पैरामीटर, पुष्टि किए जाने वाले कॉन्टेंट की जानकारी देते हैं. मान लें कि आपने AdMob को इनाम वाले कॉलबैक, https://www.myserver.com/mypath पर भेजने के लिए कॉन्फ़िगर किया है. यहां दिए गए स्निपेट में, इनाम वाले विज्ञापन के लिए, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक का एक उदाहरण दिखाया गया है. इसमें, पुष्टि किए जाने वाले कॉन्टेंट को हाइलाइट किया गया है.
https://www.myserver.com/path?ad_network=54...55&ad_unit=12345678&reward_amount=10&reward_item=coins ×tamp=150777823&transaction_id=12...DEF&user_id=1234567&signature=ME...Z1c&key_id=1268887
यहां दिए गए कोड में, कॉलबैक यूआरएल से पुष्टि किए जाने वाले कॉन्टेंट को UTF-8 बाइट ऐरे के तौर पर पार्स करने का तरीका बताया गया है.
public static final String SIGNATURE_PARAM_NAME = "signature=";
...
URI uri;
try {
uri = new URI(rewardUrl);
} catch (URISyntaxException ex) {
throw new GeneralSecurityException(ex);
}
String queryString = uri.getQuery();
int i = queryString.indexOf(SIGNATURE_PARAM_NAME);
if (i == -1) {
throw new GeneralSecurityException("needs a signature query parameter");
}
byte[] queryParamContentData =
queryString
.substring(0, i - 1)
// i - 1 instead of i because of & in the query string
.getBytes(Charset.forName("UTF-8"));
कॉलबैक यूआरएल से सिग्नेचर और key_id पाना
पिछले चरण से मिली queryString वैल्यू का इस्तेमाल करके, कॉलबैक यूआरएल से signature और key_id क्वेरी पैरामीटर को पार्स करें. इसके लिए, यहां दिया गया तरीका अपनाएं:
public static final String KEY_ID_PARAM_NAME = "key_id=";
...
String sigAndKeyId = queryString.substring(i);
i = sigAndKeyId.indexOf(KEY_ID_PARAM_NAME);
if (i == -1) {
throw new GeneralSecurityException("needs a key_id query parameter");
}
String sig =
sigAndKeyId.substring(
SIGNATURE_PARAM_NAME.length(), i - 1 /* i - 1 instead of i because of & */);
int keyId = Integer.valueOf(sigAndKeyId.substring(i + KEY_ID_PARAM_NAME.length()));
पुष्टि करना
आखिरी चरण में, कॉलबैक यूआरएल के कॉन्टेंट की पुष्टि, सही सार्वजनिक कुंजी से की जाती है. parsePublicKeysJson तरीके से मिली मैपिंग लें और उस मैपिंग से सार्वजनिक कुंजी पाने के लिए, कॉलबैक यूआरएल से key_id पैरामीटर का इस्तेमाल करें. इसके बाद, उस सार्वजनिक कुंजी से सिग्नेचर की पुष्टि करें. verify तरीके में, इन चरणों को यहां दिखाया गया है.
private void verify(final byte[] dataToVerify, int keyId, final byte[] signature)
throws GeneralSecurityException {
Map<Integer, ECPublicKey> publicKeys = parsePublicKeysJson();
if (publicKeys.containsKey(keyId)) {
foundKeyId = true;
ECPublicKey publicKey = publicKeys.get(keyId);
EcdsaVerifyJce verifier = new EcdsaVerifyJce(publicKey, HashType.SHA256, EcdsaEncoding.DER);
verifier.verify(signature, dataToVerify);
} else {
throw new GeneralSecurityException("cannot find verifying key with key ID: " + keyId);
}
}
अगर यह तरीका, कोई अपवाद दिखाए बिना काम करता है, तो कॉलबैक यूआरएल की पुष्टि हो गई है.
अक्सर पूछे जाने वाले सवाल
- क्या मैं AdMob की सर्वर कुंजी से मिली सार्वजनिक कुंजी को कैश कर सकता/सकती हूं?
- हमारा सुझाव है कि AdMob की सर्वर कुंजी से मिली सार्वजनिक कुंजी को कैश करें. इससे, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि करने के लिए ज़रूरी कार्रवाइयों की संख्या कम हो जाएगी. हालांकि, ध्यान दें कि सार्वजनिक कुंजियां, समय-समय पर रोटेट की जाती हैं. इसलिए, इन्हें 24 घंटे से ज़्यादा समय के लिए कैश नहीं किया जाना चाहिए.
- AdMob की सर्वर कुंजी से मिली सार्वजनिक कुंजियां, कितनी बार रोटेट की जाती हैं?
- AdMob की सर्वर कुंजी से मिली सार्वजनिक कुंजियां, अलग-अलग शेड्यूल के हिसाब से रोटेट की जाती हैं. यह पक्का करने के लिए कि सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक की पुष्टि, उम्मीद के मुताबिक काम करती रहे, सार्वजनिक कुंजियों को 24 घंटे से ज़्यादा समय के लिए कैश नहीं किया जाना चाहिए.
- अगर मेरे सर्वर तक नहीं पहुंचा जा सकता, तो क्या होगा?
- Google को सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक के लिए,
HTTP 200 OKस्टेटस वाला जवाब कोड चाहिए. अगर आपके सर्वर तक नहीं पहुंचा जा सकता या वह उम्मीद के मुताबिक जवाब नहीं देता है, तो Google, सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक को एक-एक सेकंड के अंतराल पर, पांच बार भेजने की कोशिश करेगा. - मैं यह कैसे पुष्टि कर सकता/सकती हूं कि सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक, Google से आ रहे हैं?
- रिवर्स डीएनएस लुकअप का इस्तेमाल करके, यह पुष्टि करें कि सर्वर-साइड से की जाने वाली पुष्टि (एसएसवी) के कॉलबैक, Google से आ रहे हैं.