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 Console का इस्तेमाल करके, रजिस्टर किया जाता है. इसके बाद, Google आपको क्लाइंट आईडी और क्लाइंट सीक्रेट जैसी जानकारी देगा.
  2. Google API Console में 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 टैग मैनेजर डेटा की उपयोगकर्ता अनुमतियां मैनेज करें.
https://www.googleapis.com/auth/tagmanager.manage.accounts अपने Google Tag Manager खातों को मैनेज करें.

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

शुरू करें

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

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

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

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

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

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

वेब सर्वर

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

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

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

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

उदाहरण:
  • ज़रूरत के हिसाब से ब्राउज़र को कॉन्फ़िगर करने वाला टूल.

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

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

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

सेवा खाते

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

समस्या का हल

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

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

OAuth 2.0 Playground

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

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

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

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