Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

सर्वर-साइड से की जाने वाली पुष्टि (SSV) के कॉलबैक की पुष्टि करना

सर्वर-साइड पर की गई पुष्टि के कॉलबैक, यूआरएल के ऐसे अनुरोध होते हैं जिनमें Google, क्वेरी पैरामीटर जोड़ता है. Google, इन अनुरोधों को किसी बाहरी सिस्टम को भेजता है, ताकि उसे यह सूचना दी जा सके कि इनाम वाले या इनाम वाले इंटरस्टीशियल विज्ञापन के साथ इंटरैक्ट करने पर, उपयोगकर्ता को इनाम दिया जाना चाहिए. इनाम वाले विज्ञापन के लिए, सर्वर-साइड पर की गई पुष्टि (एसएसवी) के कॉलबैक, उपयोगकर्ताओं को इनाम देने के लिए, क्लाइंट-साइड पर की गई पुष्टि के कॉलबैक की स्पूफ़िंग से सुरक्षा की एक और लेयर उपलब्ध कराते हैं.

इस गाइड में, इनाम वाले विज्ञापन के लिए, सर्वर-साइड पर की गई पुष्टि के कॉलबैक की पुष्टि करने का तरीका बताया गया है. इसके लिए, Tink Java Apps की तीसरे पक्ष की क्रिप्टोग्राफ़िक लाइब्रेरी का इस्तेमाल किया जाता है. इससे यह पक्का किया जा सकता है कि कॉलबैक में मौजूद क्वेरी पैरामीटर, मान्य वैल्यू हों. हालांकि, इस गाइड में Tink का इस्तेमाल किया गया है, लेकिन आपके पास ECDSA के साथ काम करने वाली किसी भी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल करने का विकल्प है. AdMob यूज़र इंटरफ़ेस (यूआई) में मौजूद testing tool की मदद से, अपने सर्वर की जांच भी की जा सकती है.

ज़रूरी शर्तें

अपनी विज्ञापन यूनिट पर, इनाम वाले विज्ञापन के लिए, सर्वर-साइड पर की गई पुष्टि की सुविधा चालू करें.

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
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 क्वेरी पैरामीटर की वैल्यू, सर्वर-साइड पर की गई पुष्टि के कॉलबैक में मौजूद नहीं होगी.

यहां दिए गए कोड के सैंपल से पता चलता है कि इनाम वाला विज्ञापन लोड होने के बाद, सर्वर-साइड पर की गई पुष्टि के विकल्प कैसे सेट किए जाते हैं:

private void LoadRewardedAd(string adUnitId)
{
  // Send the request to load the ad.
  AdRequest adRequest = new AdRequest();
  RewardedAd.Load(adUnitId, adRequest, (RewardedAd rewardedAd, LoadAdError error) =>
  {
    // If the operation failed with a reason.
    if (error != null)
    {
        Debug.LogError("Rewarded ad failed to load an ad with error : " + error);
        return;
    }

    var options = new ServerSideVerificationOptions
                          .Builder()
                          .SetCustomData("SAMPLE_CUSTOM_DATA_STRING")
                          .Build()
    rewardedAd.SetServerSideVerificationOptions(options);
  });
}

अगर आपको कस्टम इनाम स्ट्रिंग सेट करनी है, तो आपको विज्ञापन दिखाने से पहले ऐसा करना होगा.

इनाम वाले विज्ञापन के लिए, सर्वर-साइड पर की गई पुष्टि की मैन्युअल तरीके से पुष्टि करना

इनाम वाले विज्ञापन के लिए, सर्वर-साइड पर की गई पुष्टि की पुष्टि करने के लिए, 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
&timestamp=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 से आ रहे हैं, रिवर्स डीएनएस लुकअप का इस्तेमाल करें.