इस गाइड में बताया गया है कि कोई ऐप्लिकेशन, User Deletion API को भेजे गए अनुरोधों की पुष्टि कैसे करता है.
अनुरोधों को अनुमति दें
Google Analytics की वेबसाइट पर अपने खाते की जानकारी देखने के लिए, उपयोगकर्ताओं को पहले अपने Google खातों में साइन इन करना होगा. इसी तरह, जब उपयोगकर्ता पहली बार आपके ऐप्लिकेशन को ऐक्सेस करते हैं, तब उन्हें आपके ऐप्लिकेशन को अपना डेटा ऐक्सेस करने की अनुमति देनी होती है.
आपका ऐप्लिकेशन, Analytics API को जो भी अनुरोध भेजता है उसमें अनुमति वाला टोकन होना ज़रूरी है. इस टोकन से Google आपके ऐप्लिकेशन की पहचान भी करता है.
अनुमति देने के प्रोटोकॉल के बारे में जानकारी
अनुरोधों को अनुमति देने के लिए, आपके ऐप्लिकेशन में OAuth 2.0 का इस्तेमाल किया जाना चाहिए. अनुमति देने वाले दूसरे प्रोटोकॉल इस्तेमाल नहीं किए जा सकते. अगर आपका ऐप्लिकेशन Google से साइन इन करने की सुविधा इस्तेमाल करता है, तो अनुमति देने से जुड़े कुछ पहलुओं को Google आपके लिए खुद मैनेज करता है.
OAuth 2.0 से अनुरोधों को अनुमति देना
Analytics API को भेजे गए सभी अनुरोधों के लिए अनुमति किसी ऐसे उपयोगकर्ता को देनी चाहिए जिसके पास ऐसा करने का अधिकार हो.
OAuth 2.0 के लिए अनुमति देने की प्रक्रिया या "तरीका" अलग-अलग हो सकता है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस तरह का है. सभी तरह के ऐप्लिकेशन के लिए नीचे दी गई सामान्य प्रक्रिया लागू होती है:
- ऐप्लिकेशन बनाने के बाद, उसे Google API Console का इस्तेमाल करके, रजिस्टर किया जाता है. इसके बाद, Google आपको क्लाइंट आईडी और क्लाइंट सीक्रेट जैसी जानकारी देगा.
- Google API Console में Analytics API को चालू करें. (अगर एपीआई को 'API कंसोल' की सूची में नहीं जोड़ा गया है, तो यह चरण छोड़ दें.)
- जब आपके ऐप्लिकेशन को उपयोगकर्ता के डेटा को ऐक्सेस करने की ज़रूरत होती है, तब वह Google से, डेटा के खास लिंक का अनुरोध करता है.
- Google, उपयोगकर्ता को सहमति वाली स्क्रीन दिखाता है, जिसमें उनसे आपके ऐप्लिकेशन को उनके कुछ डेटा को ऐक्सेस करने की अनुमति मांगी जाती है.
- अगर उपयोगकर्ता इसकी अनुमति दे देता है, तो Google आपके ऐप्लिकेशन को कुछ समय के लिए इस्तेमाल किए जा सकने वाला ऐक्सेस टोकन देता है.
- आपका ऐप्लिकेशन, ऐक्सेस टोकन से उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करता है.
- अगर Google को पता चलता है कि आपका अनुरोध और टोकन मान्य है, तो वह आपके ऐप्लिकेशन को अनुरोध किए गए डेटा का ऐक्सेस दे देता है.
कुछ तरीकों में दूसरे चरण भी शामिल हो सकते हैं, जैसे कि रिफ़्रेश टोकन इस्तेमाल करके, नया ऐक्सेस टोकन पाना. अलग-अलग तरह के ऐप्लिकेशन के लिए डेटा ऐक्सेस करने के तरीकों के बारे में ज़्यादा जानकारी पाने के लिए, Google का OAuth 2.0 दस्तावेज़ पढ़ें.
यहां Analytics API के लिए, OAuth 2.0 का इस्तेमाल करके अनुमति के लिए अनुरोध करने के बारे में जानकारी दी गई है:
| दायरा | मतलब |
|---|---|
https://www.googleapis.com/auth/analytics.user.deletion |
User Deletion API का इस्तेमाल करके डेटा मिटाएं. |
OAuth 2.0 का इस्तेमाल करके, डेटा ऐक्सेस करने का अनुरोध करने के लिए, आपके ऐप्लिकेशन को अनुरोध के तरीके की जानकारी देनी होगी. साथ ही, वह जानकारी भी देनी होगी जो आपको ऐप्लिकेशन रजिस्टर करते समय, Google से मिली थी, जैसे कि क्लाइंट आईडी और क्लाइंट सीक्रेट.
सलाह: Google API की क्लाइंट लाइब्रेरी आपके लिए अनुमति देने की कुछ प्रक्रियाएं खुद कर सकती है. ये लाइब्रेरी कई प्रोग्रामिंग भाषाओं के लिए उपलब्ध होती हैं. ज़्यादा जानकारी के लिए लाइब्रेरी और नमूनों वाला पेज देखें.
OAuth 2.0 के सामान्य फ़्लो
यहां दी गई सूची में, OAuth 2.0 के कुछ फ़्लो के इस्तेमाल के सामान्य उदाहरण दिए गए हैं:
वेब सर्वर
यह फ़्लो, उपयोगकर्ता के Google Analytics डेटा को अपने-आप, ऑफ़लाइन या शेड्यूल किए गए तरीके से ऐक्सेस करने के लिए सही है.
उदाहरण:
- Google Analytics के नए डेटा के साथ, उपयोगकर्ता के डैशबोर्ड अपने-आप अपडेट होते हैं.
क्लाइंट-साइड
यह फ़्लो उन ऐप्लिकेशन के लिए सबसे सही है जिनमें उपयोगकर्ता, ब्राउज़र में Google Analytics का डेटा ऐक्सेस करने के लिए सीधे ऐप्लिकेशन से इंटरैक्ट करते हैं. इससे सर्वर-साइड की क्षमताओं की ज़रूरत नहीं पड़ती. हालांकि, इससे अपने-आप, ऑफ़लाइन या शेड्यूल की गई रिपोर्टिंग करना मुश्किल हो जाता है.
उदाहरण:
- ब्राउज़र पर काम करने वाला रिपोर्टिंग टूल, जैसे कि Analytics क्वेरी एक्सप्लोरर.
इंस्टॉल किए गए ऐप्लिकेशन
यह फ़्लो उन ऐप्लिकेशन के लिए है जिन्हें पैकेज के तौर पर डिस्ट्रिब्यूट किया जाता है और उपयोगकर्ता उन्हें इंस्टॉल करते हैं. इस फ़्लो के लिए, ऐप्लिकेशन या उपयोगकर्ता के पास ब्राउज़र का ऐक्सेस होना ज़रूरी है, ताकि पुष्टि करने की प्रोसेस पूरी की जा सके.
उदाहरण:
- पीसी या Mac पर डेस्कटॉप विजेट.
- कॉन्टेंट मैनेजमेंट सिस्टम के लिए प्लगिन — वेब सर्वर या क्लाइंट-साइड की तुलना में इस फ़्लो का फ़ायदा यह है कि आपके ऐप्लिकेशन के लिए, एक ही API Console प्रोजेक्ट का इस्तेमाल किया जा सकता है. इससे उपयोगकर्ताओं को एक ही रिपोर्ट मिलती है और वे इसे आसानी से इंस्टॉल कर पाते हैं.
सेवा खाते
सेवा खाते, आपके खाते के लिए Google Analytics डेटा को अपने-आप, ऑफ़लाइन या शेड्यूल किए गए तरीके से ऐक्सेस करने के लिए फ़ायदेमंद होते हैं. उदाहरण के लिए, अपने Google Analytics डेटा का लाइव डैशबोर्ड बनाने और उसे अन्य उपयोगकर्ताओं के साथ शेयर करने के लिए.
Analytics API का इस्तेमाल शुरू करने से पहले, आपको सेटअप टूल इस्तेमाल करना होगा. यह आपको Google API Console में प्रोजेक्ट बनाने और एपीआई की सुविधा चालू करने के बारे में जानकारी देता है.
नया सेवा खाता सेट अप करने के लिए, यह तरीका अपनाएं:
- क्रेडेंशियल बनाएं > सेवा खाते की पर क्लिक करें.
- चुनें कि सेवा खाते की सार्वजनिक/निजी कुंजी को स्टैंडर्ड P12 फ़ाइल के तौर पर डाउनलोड करना है या JSON फ़ाइल के तौर पर. JSON फ़ाइल को Google API क्लाइंट लाइब्रेरी से लोड किया जा सकता है.
आपके नए सार्वजनिक/निजी पासकोड को कंप्यूटर में बनाया और डाउनलोड किया जाता है. यह पासकोड की इकलौती कॉपी होती है. इसे सुरक्षित रखने की ज़िम्मेदारी आपकी है.
समस्या का हल
इन स्थितियों में, आपको अनुमति नहीं मिलती:
अगर आपके
access_tokenकी समयसीमा खत्म हो गई है या एपीआई के लिए गलत स्कोप का इस्तेमाल किया जा रहा है, तो आपको401स्टेटस कोड मिलेगा.अगर अनुमति पा चुके उपयोगकर्ता के पास व्यू (प्रोफ़ाइल) का ऐक्सेस नहीं है, तो आपको
403स्टेटस कोड मिलेगा. पक्का करें कि आपके पास सही उपयोगकर्ता के तौर पर अनुमति हो. साथ ही, यह भी पक्का करें कि उस उपयोगकर्ता के पास वही व्यू (प्रोफ़ाइल) हो जिसे आपने चुना है.
OAuth 2.0 Playground
इस टूल की मदद से, वेब इंटरफ़ेस के ज़रिए अनुमति देने की पूरी प्रोसेस को पूरा किया जा सकता है. यह टूल, एचटीटीपी अनुरोध के सभी ज़रूरी हेडर भी दिखाता है. इनकी ज़रूरत, अनुमति वाली क्वेरी करने के लिए होती है. अगर आपको अपने ऐप्लिकेशन में अनुमति नहीं मिल रही है, तो OAuth 2.0 playground के ज़रिए अनुमति पाने की कोशिश करें. इसके बाद, प्लेग्राउंड से मिले एचटीटीपी हेडर और अनुरोध की तुलना, Google Analytics को भेजे जा रहे आपके ऐप्लिकेशन के एचटीटीपी हेडर और अनुरोध से की जा सकती है. इस जांच से यह पक्का किया जा सकता है कि आपने अपने अनुरोधों को सही तरीके से फ़ॉर्मैट किया है.
अमान्य अनुमति
रीफ़्रेश टोकन का इस्तेमाल करने पर, आपको यह invalid_grant गड़बड़ी दिखती है:
- आपके सर्वर की घड़ी, नेटवर्क टाइम प्रोटोकॉल - एनटीपी के साथ सिंक नहीं है.
- रीफ़्रेश टोकन की सीमा पार हो गई है.
ऐप्लिकेशन, एक Google Analytics खाते को ऐक्सेस करने के लिए कई रीफ़्रेश टोकन का अनुरोध कर सकते हैं.
उदाहरण के लिए, अगर किसी उपयोगकर्ता को एक ही Google Analytics खाते को कई मशीनों पर ऐक्सेस करना है, तो उसे हर मशीन के लिए अलग टोकन की ज़रूरत होगी. जब रीफ़्रेश टोकन की संख्या तय सीमा से ज़्यादा हो जाती है, तो पुराने टोकन अमान्य हो जाते हैं. अगर ऐप्लिकेशन, अमान्य रीफ़्रेश टोकन का इस्तेमाल करने की कोशिश करता है, तो invalid_grant गड़बड़ी वाला जवाब मिलता है.
OAuth 2.0 क्लाइंट और Google Analytics खाते के हर यूनीक पेयर के लिए, 25 रीफ़्रेश टोकन की सीमा तय की गई है. अगर ऐप्लिकेशन, एक ही क्लाइंट/खाते के जोड़े के लिए रीफ़्रेश टोकन का अनुरोध करता रहता है, तो 26वां टोकन जारी होने के बाद, पहले जारी किया गया पहला रीफ़्रेश टोकन अमान्य हो जाएगा. रिफ़्रेश करने के लिए 27वें अनुरोध पर, पहले जारी किया गया दूसरा टोकन अमान्य हो जाएगा. इसी तरह, आगे भी ऐसा होता रहेगा.