'Google साइन इन' से माइग्रेट करना

इस गाइड से, आपको पुष्टि करने के लिए, ज़रूरी बदलावों को समझने और JavaScript लाइब्रेरी को Google साइन इन प्लैटफ़ॉर्म लाइब्रेरी से, नई Google Identity Services लाइब्रेरी पर माइग्रेट करने के चरणों को समझने में मदद मिलती है.

अगर आपका क्लाइंट, अनुमति देने के लिए JavaScript के लिए Google API क्लाइंट लाइब्रेरी या किसी दूसरी लाइब्रेरी का इस्तेमाल कर रहा है, तो ज़्यादा जानकारी के लिए, Google Identity Services पर माइग्रेट करना लेख पढ़ें.

पुष्टि करना और अनुमति देना

पुष्टि से यह पता चलता है कि कोई व्यक्ति कौन है. इसे आम तौर पर उपयोगकर्ता का साइन-अप या साइन-इन कहा जाता है. अनुमति देना, डेटा या संसाधनों का ऐक्सेस देने या अस्वीकार करने की प्रोसेस है. उदाहरण के लिए, आपका ऐप्लिकेशन उपयोगकर्ता के Google Drive को ऐक्सेस करने के लिए, उपयोगकर्ता की सहमति का अनुरोध करता है.

'Google साइन-इन' प्लैटफ़ॉर्म की पिछली लाइब्रेरी की तरह ही, नई Google Identity Services लाइब्रेरी को भी पुष्टि करने और अनुमति देने की प्रोसेस को पूरा करने के लिए बनाया गया है.

हालांकि, नई लाइब्रेरी में इन दोनों प्रोसेस को अलग-अलग रखा गया है, ताकि डेवलपर को आपके ऐप्लिकेशन में Google खातों को इंटिग्रेट करने में आसानी हो.

अगर आपके इस्तेमाल के उदाहरण में सिर्फ़ पुष्टि करने की बात है, तो इस पेज को पढ़ना जारी रखें.

अगर आपके इस्तेमाल के उदाहरण में अनुमति शामिल है, तो यह पक्का करने के लिए कि आपका ऐप्लिकेशन नए और बेहतर एपीआई का इस्तेमाल कर रहा है, उपयोगकर्ता की अनुमति के काम करने का तरीका और Google Identity Services पर माइग्रेट करें लेख पढ़ें.

कौनसे बदलाव हुए हैं

उपयोगकर्ताओं के लिए, Google Identity Services लाइब्रेरी की नई सुविधाओं में, इस्तेमाल करने के तरीके से जुड़े कई सुधार किए गए हैं. हाइलाइट में ये शामिल हैं:

• कम मुश्किलों के साथ, One Tap और अपने-आप साइन-इन होने की सुविधा पाएं.
• उपयोगकर्ताओं को उनकी पसंद के हिसाब से बनाने के साथ-साथ, 'साइन-इन करें' बटन रीफ़्रेश किया गया हो.
• वेब पर एक जैसी ब्रैंडिंग और साइन-इन करने का एक जैसा तरीका, उपयोगकर्ताओं के अनुभव को बेहतर बनाता है और उनका भरोसा बढ़ाता है,
• तुरंत कॉन्टेंट ऐक्सेस कर सकते हैं. उपयोगकर्ता आपकी साइट पर कहीं से भी सीधे साइन-अप और साइन-इन कर सकते हैं. इसके लिए, उन्हें पहले लॉगिन या खाता पेज पर जाने की ज़रूरत नहीं होती.

डेवलपर के लिए, हमारा मकसद इस प्रोसेस को आसान बनाना, सुरक्षा को बेहतर बनाना, और इंटिग्रेशन को जल्द से जल्द पूरा करना है. इनमें से कुछ सुधारों में ये शामिल हैं:

• सिर्फ़ एचटीएमएल का इस्तेमाल करके, अपनी साइट के स्टैटिक कॉन्टेंट में उपयोगकर्ता साइन-इन जोड़ने का विकल्प,
• साइन इन की पुष्टि को अनुमति देने और उपयोगकर्ता के डेटा को शेयर करने से अलग करने के बाद, अब उपयोगकर्ताओं को अपनी साइट पर साइन इन कराने के लिए, OAuth 2.0 इंटिग्रेशन की जटिल प्रक्रिया की ज़रूरत नहीं है,
• पॉप-अप और रीडायरेक्ट मोड, दोनों की सुविधाएं पहले की तरह काम करती रहेंगी. हालांकि, Google का OAuth 2.0 इन्फ़्रास्ट्रक्चर अब आपके बैकएंड सर्वर के लॉगिन एंडपॉइंट पर रीडायरेक्ट करता है,
• Google Identity और Google API की पुरानी दोनों JavaScript लाइब्रेरी की सुविधाओं को एक नई लाइब्रेरी में शामिल किया गया है,
• साइन-इन के जवाबों के लिए, अब यह तय किया जा सकता है कि Promise का इस्तेमाल करना है या नहीं. साथ ही, आसानी के लिए, गेट्टर स्टाइल फ़ंक्शन के ज़रिए इनडायरेक्ट तरीके का इस्तेमाल करने की सुविधा हटा दी गई है.

साइन इन माइग्रेशन का उदाहरण

अगर आपको मौजूदा 'Google साइन इन' बटन से माइग्रेट करना है और आपको सिर्फ़ उपयोगकर्ताओं को अपनी साइट पर साइन इन कराना है, तो सबसे आसान तरीका यह है कि आप उपयोगकर्ताओं के हिसाब से बने नए बटन पर अपडेट करें. ऐसा करने के लिए, JavaScript लाइब्रेरी को बदलें और नए साइन-इन ऑब्जेक्ट का इस्तेमाल करने के लिए, अपने कोडबेस को अपडेट करें.

लाइब्रेरी और कॉन्फ़िगरेशन

उपयोगकर्ता की पुष्टि करने और अनुमति देने के लिए, अब Google Sign-In की पुरानी प्लैटफ़ॉर्म लाइब्रेरी: apis.google.com/js/platform.js और JavaScript के लिए Google API क्लाइंट लाइब्रेरी: gapi.client की ज़रूरत नहीं है. इन्हें एक नई Google Identity Services JavaScript लाइब्रेरी से बदल दिया गया है: accounts.google.com/gsi/client.

साइन इन करने के लिए इस्तेमाल किए जाने वाले, शुरुआती तीन JavaScript मॉड्यूल: api, client, और platform, apis.google.com से लोड किए गए हैं. आम तौर पर, आपकी साइट में पिछली लाइब्रेरी को शामिल करने की जगहों की पहचान करने के लिए:

• साइन इन करने के लिए डिफ़ॉल्ट बटन apis.google.com/js/platform.js लोड होता है,
• कस्टम बटन ग्राफ़िक apis.google.com/js/api:client.js लोड होता है और
• gapi.client का डायरेक्ट इस्तेमाल से apis.google.com/js/api.js लोड होता है.

ज़्यादातर मामलों में, अपने मौजूदा वेब ऐप्लिकेशन के Client-ID क्रेडेंशियल का इस्तेमाल जारी रखा जा सकता है. हमारा सुझाव है कि माइग्रेशन की प्रोसेस के दौरान, हमारी OAuth 2.0 की नीतियों की समीक्षा करें और Google API कंसोल का इस्तेमाल करके, पुष्टि करें. साथ ही, ज़रूरत पड़ने पर इन क्लाइंट सेटिंग को अपडेट करें:

• आपके टेस्ट और प्रोडक्शन ऐप्लिकेशन अलग-अलग प्रोजेक्ट का इस्तेमाल करते हैं और उनके पास अपने क्लाइंट आईडी होते हैं,
• OAuth 2.0 क्लाइंट आईडी का टाइप "वेब ऐप्लिकेशन" हो, और
• एचटीटीपीएस का इस्तेमाल, अनुमति वाले JavaScript ऑरिजिन और रीडायरेक्ट यूआरआई के लिए किया जाता है.

जिस कोड पर असर पड़ा है उसकी पहचान करना और उसे टेस्ट करना

डीबग कुकी की मदद से, उस कोड का पता लगाया जा सकता है जिस पर असर पड़ा है. साथ ही, उस नीति के बंद होने के बाद की गतिविधि की जांच की जा सकती है.

बड़े या जटिल ऐप्लिकेशन में, gapi.auth2 मॉड्यूल के बंद होने की वजह से, जिन कोड पर असर पड़ा है उन्हें ढूंढना मुश्किल हो सकता है. जल्द ही बंद होने वाली सुविधाओं के मौजूदा इस्तेमाल को Console में लॉग करने के लिए, G_AUTH2_MIGRATION कुकी की वैल्यू को informational पर सेट करें. इसके अलावा, सेशन स्टोरेज में लॉग इन करने के लिए, कोलन जोड़ने के बाद कुंजी वैल्यू भी जोड़ें. साइन इन करने और क्रेडेंशियल मिलने के बाद, समीक्षा करें या बाद में विश्लेषण के लिए, इकट्ठा किए गए लॉग को बैकएंड पर भेजें. उदाहरण के लिए, informational:showauth2use, ऑरिजिन और यूआरएल को showauth2use नाम की सेशन स्टोरेज बटन में सेव करता है.

gapi.auth2 मॉड्यूल लोड न होने पर, ऐप्लिकेशन के व्यवहार की पुष्टि करने के लिए, G_AUTH2_MIGRATION कुकी की वैल्यू को enforced पर सेट करें. इससे, लागू होने की तारीख से पहले, बंद होने के बाद के व्यवहार की जांच की जा सकती है.

G_AUTH2_MIGRATION कुकी की संभावित वैल्यू:

• enforced gapi.auth2 मॉड्यूल लोड न करें.
• informational JS कंसोल में, बंद की गई सुविधाओं के इस्तेमाल को लॉग करें. अगर कोई वैकल्पिक पासकोड सेट किया गया है, तो सेशन स्टोरेज में भी लॉग करें: informational:key-name.

उपयोगकर्ता पर पड़ने वाले असर को कम करने के लिए, यह सुझाव दिया जाता है कि आप इस कुकी को प्रोडक्शन एनवायरमेंट में इस्तेमाल करने से पहले, डेवलपमेंट और जांच के दौरान स्थानीय तौर पर सेट करें.

एचटीएमएल और JavaScript

सिर्फ़ पुष्टि करने के लिए साइन इन करने की इस स्थिति में, मौजूदा Google साइन इन बटन का उदाहरण कोड और रेंडरिंग दिखाई गई है. पुष्टि करने के जवाब को JavaScript कॉलबैक या बैकएंड सर्वर के लॉगिन एंडपॉइंट पर सुरक्षित रीडायरेक्ट करके मैनेज करने के तरीकों में अंतर देखने के लिए, पॉप-अप या रीडायरेक्ट मोड में से किसी एक को चुनें.

पहले का तरीका

<html>
  <body>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-client_id" content="YOUR_CLIENT_ID">
    <div class="g-signin2" data-onsuccess="handleCredentialResponse"></div>
  </body>
</html>

<html>
  <body>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-client_id" content="YOUR_CLIENT_ID">
    <div class="g-signin2" data-onsuccess="handleCredentialResponse"></div>
    <script>
      function handleCredentialResponse(googleUser) {
        ...
        var xhr = new XMLHttpRequest();
        xhr.open('POST', 'https://yourbackend.example.com/tokensignin');
        xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
        xhr.onload = function() {
          console.log('Signed in as: ' + xhr.responseText);
        };
        xhr.send('idtoken=' + id_token);
      }
    </script>
  </body>
</html>

नया तरीका

सिर्फ़ पुष्टि करने के लिए साइन इन करने की सुविधा में नई लाइब्रेरी का इस्तेमाल करने के लिए, पॉप-अप या रीडायरेक्ट मोड में से किसी एक को चुनें. इसके बाद, लॉगिन पेज पर मौजूद मौजूदा कोड को बदलने के लिए, कोड सैंपल का इस्तेमाल करें.

<html>
  <body>
    <script src="https://accounts.google.com/gsi/client" async defer></script>
    <div id="g_id_onload"
         data-client_id="YOUR_CLIENT_ID"
         data-callback="handleCredentialResponse">
    </div>
    <div class="g_id_signin" data-type="standard"></div>
  </body>
</html>

<html>
  <body>
    <script src="https://accounts.google.com/gsi/client" async defer></script>
    <div id="g_id_onload"
         data-client_id="YOUR_CLIENT_ID"
         data-ux_mode="redirect"
         data-login_uri="https://www.example.com/your_login_endpoint">
    </div>
    <div class="g_id_signin" data-type="standard"></div>
  </body>
</html>

पुष्टि करने के इस उदाहरण में, नई accounts.google.com/gsi/client लाइब्रेरी, g_id_signin क्लास, और g_id_onload ऑब्जेक्ट, पिछली apis.google.com/js/platform.js लाइब्रेरी और g-signin2 ऑब्जेक्ट की जगह ले रहे हैं.

उदाहरण के तौर पर दिया गया कोड, उपयोगकर्ता के हिसाब से बनाए गए नए बटन को रेंडर करने के साथ-साथ, एक टैप वाला नया पॉप-अप भी दिखाता है. हमारा सुझाव है कि जहां भी उपयोगकर्ता के हिसाब से बटन दिखाया जाए वहां एक टैप वाला पॉप-अप भी दिखाएं. इससे साइन-अप और साइन-इन के दौरान, उपयोगकर्ता को कम परेशानी होगी.

हालांकि, साइन-इन करने के दौरान आने वाली ज़्यादा दिक्कतों की वजह से, इसका सुझाव नहीं दिया जाता है. हालांकि, आपके हिसाब से बनाए गए नए बटन को एक ही टैप में डायलॉग बॉक्स दिखाए बिना, अकेले दिखाया जा सकता है. ऐसा करने के लिए, data-auto_prompt एट्रिब्यूट को false पर सेट करें.

एचटीएमएल और JavaScript एपीआई

पिछले उदाहरण में, अपनी वेबसाइट में साइन-इन जोड़ने के लिए, नए एचटीएमएल एपीआई का इस्तेमाल करने का तरीका बताया गया है. इसके अलावा, काम करने के तरीके के हिसाब से मिलते-जुलते JavaScript API का इस्तेमाल किया जा सकता है. इसके अलावा, अपनी पूरी साइट पर एचटीएमएल और JavaScript API को मिला-जुलाकर इस्तेमाल किया जा सकता है.

बटन को पसंद के मुताबिक बनाने के विकल्पों, जैसे कि कॉलबैक टाइप और रंग, साइज़, आकार, टेक्स्ट, और थीम जैसे एट्रिब्यूट को इंटरैक्टिव तरीके से देखने के लिए, हमारा कोड जनरेटर देखें. इसका इस्तेमाल, अलग-अलग विकल्पों की तुलना करने और अपनी साइट पर इस्तेमाल करने के लिए एचटीएमएल स्निपेट जनरेट करने के लिए किया जा सकता है.

One Tap की मदद से, किसी भी पेज से साइन-इन करना

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

हमारा सुझाव है कि किसी भी पेज से साइन इन करने की सुविधा चालू करने के लिए, अपनी पूरी साइट पर मौजूद शेयर किए गए हेडर, फ़ुटर या किसी अन्य ऑब्जेक्ट में g_id_onload शामिल करें.

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

टोकन रिस्पॉन्स

उपयोगकर्ता के साइन इन करने के लिए, अब आपको OAuth 2.0 के ऑथराइज़ेशन कोड, ऐक्सेस टोकन या रीफ़्रेश टोकन को समझने या उनका इस्तेमाल करने की ज़रूरत नहीं है. इसके बजाय, साइन इन का स्टेटस और उपयोगकर्ता की प्रोफ़ाइल शेयर करने के लिए, JSON Web Token (JWT) आईडी टोकन का इस्तेमाल किया जाता है. उपयोगकर्ता प्रोफ़ाइल के डेटा के साथ काम करने के लिए, अब आपको "getter" स्टाइल के ऐक्सेस करने वाले तरीकों का इस्तेमाल करने की ज़रूरत नहीं है.

Google के हस्ताक्षर वाला सुरक्षित JWT आईडी टोकन क्रेडेंशियल, इनमें से किसी एक स्थिति में दिखाया जाता है:

• उपयोगकर्ता के ब्राउज़र पर आधारित JavaScript कॉलबैक हैंडलर के लिए, या
• रीडायरेक्ट किया जाता है. ऐसा तब होता है, जब 'Google से साइन इन करें' बटन ux_mode को redirect पर सेट किया गया हो.

दोनों मामलों में, अपने मौजूदा कॉलबैक हैंडलर को अपडेट करें. इसके लिए, ये हटाएं:

• googleUser.getBasicProfile() पर कॉल,
• BasicProfile के रेफ़रंस और getId(), getName(), getGivenName(), getFamilyName(), getImageUrl(), getEmail() के तरीकों से जुड़े कॉल, और
• AuthResponse ऑब्जेक्ट का इस्तेमाल.

इसके बजाय, उपयोगकर्ता प्रोफ़ाइल के डेटा के साथ काम करने के लिए, नए जेडब्लयूटी CredentialResponse ऑब्जेक्ट में credential सब-फ़ील्ड के डायरेक्ट रेफ़रंस का इस्तेमाल करें.

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

यह समझने के लिए कि उपयोगकर्ता आपकी साइट के साथ कैसे इंटरैक्ट कर रहे हैं, CredentialResponse में मौजूद select_by फ़ील्ड का इस्तेमाल किया जा सकता है. इससे, उपयोगकर्ता की सहमति के नतीजे और इस्तेमाल किए गए साइन-इन फ़्लो के बारे में पता चलता है.

उपयोगकर्ता की सहमति और अनुमति रद्द करना

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

उपयोगकर्ता https://myaccount.google.com/permissions पर जाकर, अनुमतियां रद्द कर सकते हैं और आपके ऐप्लिकेशन को अपने Google खाते से डिसकनेक्ट कर सकते हैं. इसके अलावा, उपयोगकर्ता आपके ऐप्लिकेशन से सीधे तौर पर डिसकनेक्ट कर सकते हैं. इसके लिए, वे आपके लागू किए गए एपीआई कॉल को ट्रिगर करते हैं. पहले इस्तेमाल किए जा रहे disconnect तरीके की जगह, अब revoke तरीका इस्तेमाल किया जा रहा है.

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

पहले, auth2.signOut() का इस्तेमाल आपके ऐप्लिकेशन से उपयोगकर्ता के साइन-आउट को मैनेज करने में किया जा सकता था. auth2.signOut() का इस्तेमाल हटा दिया जाना चाहिए. साथ ही, आपके ऐप्लिकेशन को हर उपयोगकर्ता के सेशन की स्थिति और साइन-इन की स्थिति को सीधे तौर पर मैनेज करना चाहिए.

सेशन की स्थिति और दर्शक

नई लाइब्रेरी, आपके वेब ऐप्लिकेशन के लिए साइन इन स्टेटस या सेशन स्टेटस को सेव नहीं रखती.

Google खाते के साइन इन होने की स्थिति, आपके ऐप्लिकेशन के सेशन की स्थिति, और साइन इन होने की स्थिति अलग-अलग चीज़ें हैं.

उपयोगकर्ता के Google खाते और आपके ऐप्लिकेशन में साइन इन की स्थिति, एक-दूसरे से अलग होती है. हालांकि, साइन-इन करने के दौरान जब आपको यह पता चल जाता है कि उपयोगकर्ता की पुष्टि हो गई है और उसने अपने Google खाते में साइन इन कर लिया है, तब यह स्थिति अलग-अलग होती है.

अगर आपकी साइट पर 'Google से साइन इन करें', 'एक टैप' या अपने-आप साइन इन करने की सुविधा शामिल है, तो उपयोगकर्ताओं को इन कामों के लिए, पहले अपने Google खाते में साइन इन करना होगा:

• आपकी साइट पर पहली बार साइन-अप या साइन-इन करते समय, अपनी उपयोगकर्ता प्रोफ़ाइल शेयर करने की सहमति दें,
• पर साइन-इन करने और बाद में अपनी साइट पर वापस आने के लिए किया जा सकता है.

उपयोगकर्ता आपकी वेबसाइट पर साइन इन किए हुए सेशन को चालू रखते हुए, साइन इन रह सकते हैं, साइन आउट कर सकते हैं या किसी दूसरे Google खाते पर स्विच कर सकते हैं.

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

auth2.attachClickHandler() और इसके रजिस्टर किए गए कॉलबैक हैंडलर के सभी रेफ़रंस हटाएं.

पहले, लिसनर का इस्तेमाल, उपयोगकर्ता के Google खाते के साइन इन स्टेटस में हुए बदलावों को शेयर करने के लिए किया जाता था. अब Listener का इस्तेमाल नहीं किया जा सकता.

listen(), auth2.currentUser, और auth2.isSignedIn के सभी रेफ़रंस हटाएं.

कुकी

'Google से साइन इन करें' सुविधा, कुकी का सीमित तौर पर इस्तेमाल करती है. इन कुकी के बारे में यहां बताया गया है. Google जिन अन्य तरह की कुकी का इस्तेमाल करता है उनके बारे में ज़्यादा जानने के लिए, Google, कुकी का इस्तेमाल कैसे करता है देखें.

'Google साइन-इन प्लैटफ़ॉर्म लाइब्रेरी' के पुराने वर्शन ने जो G_ENABLED_IDPS कुकी सेट की थी उसका अब इस्तेमाल नहीं किया जाएगा.

Google Identity Services की नई लाइब्रेरी, आपके कॉन्फ़िगरेशन के विकल्पों के आधार पर, क्रॉस-डोमेन वाली इन कुकी को सेट कर सकती है:

• g_state, उपयोगकर्ता के साइन आउट होने की स्थिति सेव करता है. यह कुकी, One Tap पॉप-अप या अपने-आप साइन इन होने की सुविधा का इस्तेमाल करने पर सेट होती है,

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

  • data-ux_mode=redirect के साथ एचटीएमएल एपीआई या data-login_uri सेट होने पर या

  • ux_mode=redirect वाला JavaScript API, जहां google.accounts.id.prompt() का इस्तेमाल, One Tap या अपने-आप साइन इन होने की सुविधा दिखाने के लिए नहीं किया गया है.

अगर आपके पास कुकी मैनेज करने वाली कोई सेवा है, तो दो नई कुकी जोड़ना न भूलें. साथ ही, माइग्रेशन पूरा होने के बाद, पिछली कुकी को हटा दें.

अगर एक से ज़्यादा डोमेन या सबडोमेन मैनेज किए जा रहे हैं, तो g_state कुकी के साथ काम करने के बारे में ज़्यादा निर्देश पाने के लिए, सभी सबडोमेन में Display One Tap देखें.

उपयोगकर्ता के साइन इन करने के लिए, ऑब्जेक्ट माइग्रेशन का रेफ़रंस