इस गाइड में बताया गया है कि कोई ऐप्लिकेशन, User Deletion API के अनुरोधों को कैसे अनुमति देता है.
अनुरोधों को अनुमति दें
Google Analytics की वेबसाइट पर अपने खाते की जानकारी देखने से पहले, उपयोगकर्ताओं को अपने Google खातों में साइन इन करना होगा. इसी तरह, जब उपयोगकर्ता पहली बार आपके ऐप्लिकेशन को ऐक्सेस करते हैं, तो उन्हें अपने डेटा को ऐक्सेस करने के लिए, आपके ऐप्लिकेशन को अनुमति देनी होगी.
आपका ऐप्लिकेशन, Analytics API को जो भी अनुरोध भेजता है उसमें अनुमति वाला टोकन शामिल होना चाहिए. इस टोकन से Google आपके ऐप्लिकेशन की पहचान भी करता है.
अनुमति देने के प्रोटोकॉल के बारे में जानकारी
अनुरोधों को अनुमति देने के लिए, आपके ऐप्लिकेशन में OAuth 2.0 का इस्तेमाल किया जाना चाहिए. अनुमति देने वाले दूसरे प्रोटोकॉल इस्तेमाल नहीं किए जा सकते. अगर आपका ऐप्लिकेशन Google से साइन इन करने की सुविधा इस्तेमाल करता है, तो अनुमति देने से जुड़े कुछ पहलुओं को Google आपके लिए खुद मैनेज करता है.
OAuth 2.0 से अनुरोधों को अनुमति देना
Analytics API को भेजे गए सभी अनुरोधों के लिए अनुमति किसी ऐसे उपयोगकर्ता को देनी चाहिए जिसके पास ऐसा करने का अधिकार हो.
OAuth 2.0 के लिए अनुमति देने की प्रक्रिया या "तरीका" अलग-अलग हो सकता है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस तरह का है. सभी तरह के ऐप्लिकेशन के लिए नीचे दी गई सामान्य प्रक्रिया लागू होती है:
- ऐप्लिकेशन बनाने के बाद, उसे Google API (एपीआई) कंसोल का इस्तेमाल करके, रजिस्टर किया जाता है. इसके बाद, Google आपको क्लाइंट आईडी और क्लाइंट सीक्रेट जैसी जानकारी देगा.
- Google API कंसोल में 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 फ़ाइल के तौर पर, जिसे Google API क्लाइंट लाइब्रेरी से लोड किया जा सकता है.
आपके नए सार्वजनिक/निजी पासकोड को कंप्यूटर में बनाया और डाउनलोड किया जाता है. यह पासकोड की इकलौती कॉपी होती है. इसे सुरक्षित रखने की ज़िम्मेदारी आपकी है.
समस्या का हल
इन स्थितियों में आपको अनुमति नहीं मिलती:
अगर आपके
access_token
की समयसीमा खत्म हो गई है या एपीआई के लिए गलत स्कोप का इस्तेमाल किया जा रहा है, तो आपको401
स्टेटस कोड दिखेगा.अगर अनुमति पा चुके उपयोगकर्ता के पास व्यू (प्रोफ़ाइल) का ऐक्सेस नहीं है, तो आपको
403
स्टेटस कोड दिखेगा. पक्का करें कि आपके पास सही उपयोगकर्ता के ऐक्सेस की अनुमति हो और आपने जिस व्यू (प्रोफ़ाइल) को चुना है वह उस उपयोगकर्ता के पास हो.
OAuth 2.0 प्लेलैंड
इस टूल की मदद से, वेब इंटरफ़ेस के ज़रिए अनुमति पाने की पूरी प्रोसेस पूरी की जा सकती है. यह टूल, अनुमति वाली क्वेरी बनाने के लिए ज़रूरी सभी एचटीटीपी अनुरोध हेडर भी दिखाता है. अगर आपको अपने ऐप्लिकेशन में काम करने की अनुमति नहीं मिल पा रही है, तो आपको OAuth 2.0 प्लेलैंड की मदद से इसे काम करने की कोशिश करनी चाहिए. इसके बाद आप HTTP हेडर की तुलना करके प्लेग्राउंड से यह अनुरोध कर सकते हैं कि आपका ऐप्लिकेशन Google Analytics को क्या भेज रहा है. इस जांच से, यह पता चल पाता है कि आपके अनुरोधों का फ़ॉर्मैट सही है या नहीं.
अमान्य अनुदान
रीफ़्रेश टोकन का इस्तेमाल करने पर, आपको invalid_grant
गड़बड़ी का यह मैसेज दिखता है:
- आपके सर्वर की घड़ी, नेटवर्क टाइम प्रोटोकॉल - NTP के साथ सिंक नहीं है.
- रीफ़्रेश टोकन की सीमा पार हो गई है.
ऐप्लिकेशन, किसी एक Google Analytics खाते को ऐक्सेस करने के लिए, कई रीफ़्रेश टोकन का अनुरोध कर सकते हैं.
उदाहरण के लिए, अगर किसी उपयोगकर्ता को एक से ज़्यादा मशीनों पर ऐप्लिकेशन इंस्टॉल करना है और एक ही Google Analytics खाते को ऐक्सेस करना है, तो हर मशीन के लिए एक अलग टोकन की ज़रूरत होगी. रीफ़्रेश टोकन की संख्या तय सीमा से ज़्यादा होने पर,
पुराने टोकन अमान्य हो जाते हैं. अगर ऐप्लिकेशन किसी अमान्य रीफ़्रेश टोकन का इस्तेमाल करने की कोशिश करता है, तो invalid_grant
गड़बड़ी का रिस्पॉन्स मिलता है.
OAuth 2.0 क्लाइंट और Google Analytics खाते के हर यूनीक जोड़े के लिए, 25 रीफ़्रेश टोकन तय किए जा सकते हैं. अगर ऐप्लिकेशन एक ही क्लाइंट/खाता जोड़े के लिए रीफ़्रेश टोकन का अनुरोध करता रहता है, तो 26वां टोकन जारी होने के बाद, पहले जारी किया गया रीफ़्रेश टोकन अमान्य हो जाएगा. 27वें रीफ़्रेश टोकन का अनुरोध करने पर, पहले जारी किए गए दूसरे टोकन को अमान्य कर दिया जाएगा.