Tag Manager API की अनुमति देना

इस दस्तावेज़ में बताया गया है कि किसी ऐप्लिकेशन को Tag Manager API में अनुरोध करने की अनुमति कैसे मिल सकती है.

अनुमति देने वाले अनुरोध

Google की किसी भी साइट पर अपने खाते की जानकारी देखने के लिए, उपयोगकर्ताओं को Google खाते से लॉग इन करना होगा. इसी तरह, जब लोग पहली बार आपके ऐप्लिकेशन को ऐक्सेस करते हैं, तब उन्हें आपके ऐप्लिकेशन को अपना डेटा ऐक्सेस करने की अनुमति देनी होती है.

आपका ऐप्लिकेशन, Tag Manager API को जो भी अनुरोध भेजता है उसमें, अनुमति वाला टोकन शामिल होना चाहिए. इस टोकन से Google आपके ऐप्लिकेशन की पहचान भी करता है.

अनुमति देने के प्रोटोकॉल के बारे में जानकारी

अनुरोधों को अनुमति देने के लिए, आपके ऐप्लिकेशन में OAuth 2.0 का इस्तेमाल किया जाना चाहिए. अनुमति देने वाले दूसरे प्रोटोकॉल इस्तेमाल नहीं किए जा सकते. अगर आपका ऐप्लिकेशन Google से साइन इन करने की सुविधा इस्तेमाल करता है, तो अनुमति देने से जुड़े कुछ पहलुओं को Google आपके लिए खुद मैनेज करता है.

OAuth 2.0 से अनुरोधों को अनुमति देना

Tag Manager API को किए जाने वाले सभी अनुरोधों की पुष्टि, ऐसे उपयोगकर्ता के पास होनी चाहिए जिसकी पुष्टि हो चुकी है.

OAuth 2.0 के लिए अनुमति देने की प्रक्रिया या "तरीका" अलग-अलग हो सकता है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस तरह का है. सभी तरह के ऐप्लिकेशन के लिए नीचे दी गई सामान्य प्रक्रिया लागू होती है:

  1. ऐप्लिकेशन बनाने के बाद, उसे Google API (एपीआई) कंसोल का इस्तेमाल करके, रजिस्टर किया जाता है. इसके बाद, Google आपको क्लाइंट आईडी और क्लाइंट सीक्रेट जैसी जानकारी देगा. इस जानकारी की ज़रूरत आपको बाद में पड़ेगी.
  2. Google API (एपीआई) कंसोल में Tag Manager API को चालू करें. (अगर एपीआई को 'API कंसोल' की सूची में नहीं जोड़ा गया है, तो यह चरण छोड़ दें.)
  3. जब आपके ऐप्लिकेशन को उपयोगकर्ता के डेटा को ऐक्सेस करने की ज़रूरत होती है, तब वह Google से, डेटा के खास लिंक का अनुरोध करता है.
  4. Google, उपयोगकर्ता को सहमति वाली स्क्रीन दिखाता है, जिसमें उनसे आपके ऐप्लिकेशन को उनके कुछ डेटा को ऐक्सेस करने की अनुमति मांगी जाती है.
  5. अगर उपयोगकर्ता इसकी अनुमति दे देता है, तो Google आपके ऐप्लिकेशन को कुछ समय के लिए इस्तेमाल किए जा सकने वाला ऐक्सेस टोकन देता है.
  6. आपका ऐप्लिकेशन, ऐक्सेस टोकन से उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करता है.
  7. अगर Google को पता चलता है कि आपका अनुरोध और टोकन मान्य है, तो वह आपके ऐप्लिकेशन को अनुरोध किए गए डेटा का ऐक्सेस दे देता है.

कुछ तरीकों में दूसरे चरण भी शामिल हो सकते हैं, जैसे कि रिफ़्रेश टोकन इस्तेमाल करके, नया ऐक्सेस टोकन पाना. अलग-अलग तरह के ऐप्लिकेशन के लिए डेटा ऐक्सेस करने के तरीकों के बारे में ज़्यादा जानकारी पाने के लिए, Google का OAuth 2.0 दस्तावेज़ पढ़ें.

यहां Tag Manager API के लिए, OAuth 2.0 दायरे की जानकारी दी गई है:

स्कोप मतलब
https://www.googleapis.com/auth/tagmanager.readonly अपने Google Tag Manager कंटेनर देखें.
https://www.googleapis.com/auth/tagmanager.edit.containers अपने Google Tag Manager कंटेनर मैनेज करें.
https://www.googleapis.com/auth/tagmanager.delete.containers अपने Google Tag Manager कंटेनर मिटाएं.
https://www.googleapis.com/auth/tagmanager.edit.containerversions अपने Google Tag Manager कंटेनर वर्शन मैनेज करें.
https://www.googleapis.com/auth/tagmanager.publish अपने Google Tag Manager कंटेनर पब्लिश करें.
https://www.googleapis.com/auth/tagmanager.manage.users अपने Google Tag Manager डेटा की उपयोगकर्ता अनुमतियां मैनेज करें.
https://www.googleapis.com/auth/tagmanager.manage.accounts अपने Google Tag Manager खाते मैनेज करें.

OAuth 2.0 का इस्तेमाल करके, डेटा ऐक्सेस करने का अनुरोध करने के लिए, आपके ऐप्लिकेशन को अनुरोध के तरीके की जानकारी देनी होगी. साथ ही, वह जानकारी भी देनी होगी जो आपको ऐप्लिकेशन रजिस्टर करते समय, Google से मिली थी, जैसे कि क्लाइंट आईडी और क्लाइंट सीक्रेट.

YouTube पर शुरुआत करना

Tag Manager API का इस्तेमाल शुरू करने से पहले, सेटअप टूल इस्तेमाल करना ज़रूरी है. यह आपको Google API Console में प्रोजेक्ट बनाने, एपीआई की सुविधा चालू करने, और क्रेडेंशियल बनाने के बारे में जानकारी देता है.

नया सेवा खाता सेट अप करने के लिए, ये काम करें:

  1. क्रेडेंशियल बनाएं > सेवा खाता कुंजी पर क्लिक करें.
  2. चुनें कि सेवा खाते की सार्वजनिक/निजी कुंजी को स्टैंडर्ड P12 फ़ाइल के तौर पर डाउनलोड करना है या ऐसी JSON फ़ाइल के तौर पर जिसे Google API क्लाइंट लाइब्रेरी से लोड किया जा सकता है.

आपके नए सार्वजनिक/निजी पासकोड को कंप्यूटर में बनाया और डाउनलोड किया जाता है. यह पासकोड की इकलौती कॉपी होती है. इसके सुरक्षित रूप से संग्रहित करने की ज़िम्मेदारी आपकी है.

OAuth 2.0 के सामान्य फ़्लो

यहां दिए गए दिशा-निर्देशों से, OAuth 2.0 के खास फ़्लो के इस्तेमाल के सामान्य उदाहरणों के बारे में बताया गया है:

वेब सर्वर

यह फ़्लो, किसी उपयोगकर्ता के Google Tag Manager खाते के लिए, ऑटोमेटेड/ऑफ़लाइन/शेड्यूल किए गए ऐक्सेस के लिए अच्छा है.

उदाहरण:
  • सर्वर से Tag Manager की जानकारी अपने-आप अपडेट होने की सुविधा.

क्लाइंट-साइड

यह तब सबसे अच्छा विकल्प है, जब उपयोगकर्ता किसी ब्राउज़र में अपने Google Tag Manager खाते को ऐक्सेस करने के लिए, ऐप्लिकेशन से सीधे इंटरैक्ट करते हैं. इस फ़्लो की मदद से, सर्वर-साइड की क्षमताओं की ज़रूरत नहीं पड़ती. हालांकि, इसकी वजह से ऑटोमेटेड/ऑफ़लाइन/शेड्यूल की गई रिपोर्टिंग के लिए, इसे इस्तेमाल करना संभव नहीं होता.

उदाहरण:
  • पसंद के मुताबिक बनाया गया ब्राउज़र आधारित कॉन्फ़िगरेशन टूल.

इंस्टॉल किए गए ऐप्लिकेशन

ऐसे ऐप्लिकेशन जिन्हें उपयोगकर्ता ने इंस्टॉल और पैकेज के तौर पर इंस्टॉल किया है. पुष्टि करने की प्रोसेस को पूरा करने के लिए, यह ज़रूरी है कि ऐप्लिकेशन या उपयोगकर्ता के पास ब्राउज़र का ऐक्सेस हो.

उदाहरण:
  • PC या Mac पर डेस्कटॉप विजेट.
  • कॉन्टेंट मैनेजमेंट सिस्टम के लिए प्लगिन. वेब सर्वर या क्लाइंट-साइड की तुलना में इस फ़्लो का फ़ायदा यह है कि आपके ऐप्लिकेशन के लिए, एक ही एपीआई कंसोल प्रोजेक्ट का इस्तेमाल किया जा सकता है. इससे लोग ऐप्लिकेशन को आसानी से इंस्टॉल कर सकते हैं.

सेवा खाते

आपके Google Tag Manager खाते को अपने-आप/ऑफ़लाइन/शेड्यूल किए गए ऐक्सेस के लिए काम की है. उदाहरण के लिए, अपने Google Tag Manager खाते की निगरानी करने और उसे अन्य उपयोगकर्ताओं के साथ शेयर करने के लिए, कस्टम टूल बनाना.

समस्या हल करना

अगर आपके access_token की समयसीमा खत्म हो गई है या आपने किसी खास एपीआई कॉल के लिए गलत स्कोप का इस्तेमाल किया है, तो आपको रिस्पॉन्स में 401 स्टेटस कोड मिलेगा.

अगर अनुमति पा चुके उपयोगकर्ता के पास Google Tag Manager खाते या कंटेनर का ऐक्सेस नहीं है, तो आपको जवाब में 403 स्टेटस कोड मिलेगा. पक्का करें कि आपको सही उपयोगकर्ता अनुमति मिली हुई है और आपको Tag Manager खाता या कंटेनर ऐक्सेस करने की अनुमतियां दी गई हैं.

OAuth 2.0 प्लेग्राउंड

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

अमान्य अनुमति

अगर रीफ़्रेश टोकन का इस्तेमाल करते समय invalid_grant की गड़बड़ी वाला रिस्पॉन्स मिलता है, तो यह गड़बड़ी इनमें से किसी एक या दोनों वजहों से हो सकती है:

  1. आपके सर्वर की घड़ी, NTP के साथ सिंक नहीं है.
  2. आपने रीफ़्रेश टोकन की तय सीमा पार कर ली है.
    किसी एक Google Tag Manager खाते को ऐक्सेस करने के लिए, ऐप्लिकेशन कई रीफ़्रेश टोकन का अनुरोध कर सकते हैं. उदाहरण के लिए, यह उन स्थितियों में काम का है जब उपयोगकर्ता कई मशीनों पर कोई ऐप्लिकेशन इंस्टॉल करना चाहता है और एक ही Google Tag Manager खाते को ऐक्सेस करना चाहता है. इस मामले में, दो रीफ़्रेश टोकन की ज़रूरत होगी. हर इंस्टॉल के लिए एक रीफ़्रेश टोकन. जब रीफ़्रेश टोकन की संख्या तय सीमा से ज़्यादा हो जाती है, तब पुराने टोकन अमान्य हो जाते हैं. अगर ऐप्लिकेशन किसी अमान्य रीफ़्रेश टोकन का इस्तेमाल करने की कोशिश करता है, तो invalid_grant गड़बड़ी का रिस्पॉन्स मिलता है. हर यूनीक क्लाइंट-आईडी/खाता कॉम्बिनेशन में, ज़्यादा से ज़्यादा 25 रीफ़्रेश टोकन हो सकते हैं. (ध्यान दें कि इस सीमा में बदलाव हो सकता है.) अगर ऐप्लिकेशन, एक ही क्लाइंट-आईडी/खाते के कॉम्बिनेशन के लिए, रीफ़्रेश टोकन का अनुरोध करता रहता है, तो 26वां टोकन जारी होने के बाद, जारी किया गया पहला रीफ़्रेश टोकन अमान्य हो जाता है. 27वां अनुरोध किया गया रीफ़्रेश टोकन, जारी किए गए दूसरे टोकन को अमान्य कर देता है. यह क्रम इसी तरह लागू होता है.