साइन-इन करने के वर्कफ़्लो पर, तीसरे पक्ष की कुकी में किए गए बदलावों का असर देखना

Chrome, तीसरे पक्ष की कुकी के लिए उपयोगकर्ताओं को एक नया अनुभव देने का प्रस्ताव दे रहा है. आपको अपनी साइट को उन उपयोगकर्ताओं के लिए तैयार करना होगा जो तीसरे पक्ष की कुकी के बिना ब्राउज़ करना चाहते हैं.

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

अगर आपकी वेबसाइट सिर्फ़ एक ही डोमेन और सबडोमेन, जैसे कि publisher.example और login.publisher.example में फ़्लो को हैंडल करती है, तो वह क्रॉस-साइट कुकी का इस्तेमाल नहीं करेगी. साथ ही, तीसरे पक्ष की कुकी में हुए बदलावों से आपके साइन-इन फ़्लो पर कोई असर नहीं पड़ेगा.

हालांकि, अगर आपकी साइट Google साइन-इन या Facebook Login जैसे अलग-अलग डोमेन का इस्तेमाल करके लॉगिन करती है या आपकी साइट को कई डोमेन या सबडोमेन पर उपयोगकर्ता की पुष्टि की जानकारी शेयर करनी है, तो हो सकता है कि आपको अपनी साइट में बदलाव करने पड़ें. इससे, क्रॉस-साइट कुकी से आसानी से हटने में मदद मिलेगी.

उपयोगकर्ता की सामान्य गतिविधियां

पहले, पहचान से जुड़े कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर थे. टेबल में, उपयोगकर्ता के कुछ सामान्य सफ़र और इनमें से हर एक के लिए संभावित समाधान दिए गए हैं. ये समाधान, तीसरे पक्ष की कुकी पर निर्भर नहीं करते. नीचे दिए गए सेक्शन में, इन सुझावों के पीछे की वजह बताई गई है.

उपयोगकर्ता की गतिविधि सुझाए गए एपीआई
सोशल साइन-इन आइडेंटिटी प्रोवाइडर के लिए: FedCM लागू करें
भरोसेमंद पक्षों के लिए: अपने आइडेंटिटी प्रोवाइडर से संपर्क करें
फ़्रंट चैनल से लॉग आउट करना आइडेंटिटी प्रोवाइडर के लिए: FedCM लागू करें

सिंगल साइन-ऑन

आइडेंटिटी प्रोवाइडर या कस्टम सलूशन के लिए: मिलती-जुलती वेबसाइट के सेट

उपयोगकर्ता की प्रोफ़ाइल मैनेज करना Storage Access API
मिलती-जुलती वेबसाइट के सेट
CHIPS
FedCM + SAA

सदस्यताएं मैनेज करना

 Storage Access API
मिलती-जुलती वेबसाइट के सेट
CHIPS
FedCM + SAA
पुष्टि करना Storage Access API
FedCM
Web Authentication API
Partitioned Popins

उपयोगकर्ता की अन्य यात्राएं

 आम तौर पर, इन स्थितियों में तीसरे पक्ष की कुकी पर निर्भरता नहीं होती और इन पर इसका कोई असर नहीं पड़ता.

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

तीसरे पक्ष की कुकी पर पाबंदी लगाने के बाद, इन चीज़ों की जांच करें:

  • उपयोगकर्ता का रजिस्ट्रेशन: नया खाता बनाने की सुविधा उम्मीद के मुताबिक काम करती है. अगर तीसरे पक्ष के आइडेंटिटी प्रोवाइडर का इस्तेमाल किया जा रहा है, तो देखें कि हर इंटिग्रेशन के लिए नए खातों का रजिस्टरेशन काम करता है या नहीं.
  • पासवर्ड वापस पाना: पासवर्ड वापस पाने की सुविधा, वेब यूज़र इंटरफ़ेस से लेकर CAPTCHA तक, उम्मीद के मुताबिक काम करती है. साथ ही, पासवर्ड वापस पाने का ईमेल भी मिलता है.
  • साइन इन: साइन इन वर्कफ़्लो, एक ही डोमेन में और दूसरे डोमेन पर नेविगेट करते समय काम करता है. हर साइन-इन इंटिग्रेशन की जांच करना न भूलें.
  • साइन आउट: साइन आउट करने की प्रोसेस उम्मीद के मुताबिक काम करती है. साथ ही, साइन आउट करने के बाद भी उपयोगकर्ता साइन आउट ही रहता है.

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

साइन-इन करने के तरीके

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

तीसरे पक्ष का सिंगल साइन-ऑन (एसएसओ)

तीसरे पक्ष के सिंगल साइन-इन (एसएसओ) की मदद से, उपयोगकर्ता एक प्लैटफ़ॉर्म पर क्रेडेंशियल के एक सेट से पुष्टि कर सकता है. इसके बाद, लॉगिन की जानकारी फिर से डाले बिना कई ऐप्लिकेशन और वेबसाइटों को ऐक्सेस कर सकता है. एसएसओ (SSO) सलूशन को लागू करने की प्रोसेस जटिल होने की वजह से, कई कंपनियां तीसरे पक्ष के सलूशन प्रोवाइडर का इस्तेमाल करती हैं. इससे, वे एक से ज़्यादा ऑरिजिन के बीच साइन इन स्टेटस शेयर कर पाती हैं. Okta, Ping Identity, Google Cloud IAM या Microsoft Entra आईडी जैसे प्रोवाइडर के उदाहरण.

अगर आपका समाधान, तीसरे पक्ष की सेवा देने वाली कंपनी पर निर्भर है, तो हो सकता है कि लाइब्रेरी को अपग्रेड करने जैसे कुछ छोटे बदलाव ज़रूरी हों. सबसे अच्छा तरीका यह है कि आप सेवा देने वाली कंपनी से सलाह लें कि तीसरे पक्ष की कुकी की निर्भरता, समाधान पर कैसे असर डालती है और वे अपनी सेवा के लिए किस तरीके का सुझाव देते हैं. कुछ सेवा देने वाली कंपनियां, तीसरे पक्ष की कुकी का इस्तेमाल बंद कर देंगी. ऐसे में, उन पर निर्भर पार्टियों को अपडेट करने की ज़रूरत नहीं होगी.

अनेक डोमेन

कुछ वेबसाइटें, सिर्फ़ उन उपयोगकर्ताओं की पुष्टि करने के लिए किसी दूसरे डोमेन का इस्तेमाल करती हैं जो एक ही साइट की कुकी की ज़रूरी शर्तें पूरी नहीं करती हैं. जैसे, मुख्य साइट के लिए example.com और लॉगिन फ़्लो के लिए login.example का इस्तेमाल करने वाली वेबसाइट. इसके लिए, तीसरे पक्ष की कुकी को ऐक्सेस करना पड़ सकता है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता की पुष्टि दोनों डोमेन पर की गई है.

कुछ कारोबारों के पास अलग-अलग डोमेन या सबडोमेन पर होस्ट किए गए कई प्रॉडक्ट हो सकते हैं. ऐसे समाधान, उपयोगकर्ता के सेशन को उन प्रॉडक्ट के साथ शेयर करना चाह सकते हैं. ऐसे में, एक से ज़्यादा डोमेन के बीच तीसरे पक्ष की कुकी को ऐक्सेस करना पड़ सकता है.

इस स्थिति में, माइग्रेशन के ये तरीके अपनाए जा सकते हैं:

  • पहले पक्ष की ("एक ही साइट") कुकी का इस्तेमाल करने के लिए अपडेट करें: वेबसाइट के इंफ़्रास्ट्रक्चर में बदलाव करना, ताकि लॉगिन फ़्लो को मुख्य साइट के उसी डोमेन (या सबडोमेन) पर होस्ट किया जा सके जो सिर्फ़ पहले पक्ष की कुकी का इस्तेमाल करेगा. इसके लिए ज़्यादा मेहनत की ज़रूरत पड़ सकती है. यह इस बात पर निर्भर करता है कि बुनियादी ढांचा कैसे सेट अप किया गया है.
  • मिलती-जुलती वेबसाइट के सेट (RWS) और स्टोरेज ऐक्सेस एपीआई (SAA) का इस्तेमाल करें: RWS, मिलते-जुलते डोमेन के छोटे ग्रुप के बीच, क्रॉस-साइट कुकी के सीमित ऐक्सेस की सुविधा देता है. आरडब्ल्यूएस की मदद से, Storage Access API से स्टोरेज ऐक्सेस करने का अनुरोध करते समय, उपयोगकर्ता से कोई अनुरोध करने की ज़रूरत नहीं होती. इससे उन आरपी पर एसएसओ (SSO) की सुविधा मिलती है जो आईडीपी के साथ एक ही आरडब्ल्यूएस में होते हैं. हालांकि, RWS की मदद से, सिर्फ़ कुछ डोमेन के लिए ही अलग-अलग साइटों की कुकी का ऐक्सेस मिलता है.
  • Web Authentication API का इस्तेमाल करना: Web Authentication API की मदद से, भरोसेमंद पक्ष (आरपी) मिलते-जुलते ऑरिजिन का एक सीमित सेट रजिस्टर कर सकते हैं. इस सेट में क्रेडेंशियल बनाए जा सकते हैं और उनका इस्तेमाल किया जा सकता है.
  • अगर आपको पांच से ज़्यादा असोसिएटेड डोमेन के लिए उपयोगकर्ताओं की पुष्टि करनी है, तो फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM) के बारे में जानें: FedCM की मदद से, पहचान की पुष्टि करने वाली सेवाएं, पहचान से जुड़े फ़्लो को मैनेज करने के लिए Chrome पर भरोसा कर सकती हैं. इसके लिए, उन्हें तीसरे पक्ष की कुकी की ज़रूरत नहीं होती. आपके मामले में, आपका "साइन-इन डोमेन", FedCM आइडेंटिटी प्रोवाइडर के तौर पर काम कर सकता है. साथ ही, इसका इस्तेमाल आपके अन्य सभी डोमेन के उपयोगकर्ताओं की पुष्टि करने के लिए किया जा सकता है.

एम्बेड की मदद से पुष्टि करना

मान लें कि 3-party-app.example iframe, top-level.example पर एम्बेड किया गया है. 3-party-app.example पर, उपयोगकर्ता 3-party-app.example के क्रेडेंशियल या तीसरे पक्ष के किसी अन्य प्रोवाइडर के क्रेडेंशियल से लॉगिन कर सकता है.

उपयोगकर्ता, "लॉगिन करें" पर क्लिक करता है और 3-party-app.example पॉप-अप में पुष्टि करता है. 3-party-app.example पॉप-अप, पहले-पक्ष की कुकी सेट करता है. हालांकि, top-level.example पर एम्बेड किए गए 3-party-app.example iframe को अलग-अलग हिस्सों में बांटा गया है. इसलिए, यह 3-party-app.example पर पहले पक्ष के संदर्भ में सेट की गई कुकी को ऐक्सेस नहीं कर सकता.

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

यही समस्या तब भी होगी, जब उपयोगकर्ता को top-level.example से 3-party-app.example और फिर से top-level.example पर रीडायरेक्ट किया जाए. कुकी को 3-party-app.example साइट के पहले पक्ष के कॉन्टेक्स्ट में लिखा गया है, लेकिन इसे अलग-अलग हिस्सों में बांटा गया है और 3-party-app.example iframe में ऐक्सेस नहीं किया जा सकता.

तीसरे पक्ष की कुकी पर पाबंदी होने पर, आरपी वेबसाइट और तीसरे पक्ष के आईडीपी के बीच रीडायरेक्ट के साथ पुष्टि करने के फ़्लो की इमेज.
रीडायरेक्ट के साथ पुष्टि करने का तरीका: तीसरे पक्ष की कुकी पर पाबंदी होने पर, कुकी को टॉप लेवल डोमेन के कॉन्टेक्स्ट में लिखा जाता है और इसे iframe में ऐक्सेस नहीं किया जा सकता.

अगर उपयोगकर्ता ने टॉप-लेवल के कॉन्टेक्स्ट में एम्बेड किए गए ऑरिजिन पर विज़िट किया है, तो Storage Access API एक अच्छा समाधान है.

हमारा सुझाव है कि पहचान की पुष्टि करने वाली सेवा देने वाली कंपनियां, तीसरे पक्ष की कुकी पर निर्भर रहने वाले समाधानों से माइग्रेट करें. इसके लिए, वे FedCM API का इस्तेमाल करें. साथ ही, FedCM को पॉप-अप के बजाय एम्बेड किए गए कॉन्टेंट से कॉल करें.

इस फ़्लो के लिए, पार्टिशन किए गए पॉपिन का एक और सुझाया गया समाधान लागू किया जा रहा है.

सोशल साइन-इन

Google से साइन इन करें, Facebook से साइन इन करें, और Twitter से साइन इन करें जैसे साइन-इन बटन, इस बात का पक्का संकेत देते हैं कि आपकी वेबसाइट फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का इस्तेमाल कर रही है. फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का अपना तरीका होगा.

अगर Google Sign-In JavaScript प्लैटफ़ॉर्म लाइब्रेरी के अब काम न करने वाले वर्शन का इस्तेमाल किया जा रहा है, तो पुष्टि करने और अनुमति देने की प्रक्रिया के लिए, Google Identity Services की नई लाइब्रेरी पर माइग्रेट करने का तरीका जानें.

Google Identity Services की नई लाइब्रेरी का इस्तेमाल करने वाली ज़्यादातर साइटों ने तीसरे पक्ष की कुकी पर निर्भरता कम कर दी है. ऐसा इसलिए किया गया है, क्योंकि काम करने के लिए लाइब्रेरी, FedCM का इस्तेमाल करने के लिए चुपचाप माइग्रेट हो जाएगी. हमारा सुझाव है कि तीसरे पक्ष की कुकी को धीरे-धीरे हटाने की जांच करने के लिए फ़्लैग चालू करके अपनी साइट की जांच करें. साथ ही, ज़रूरत पड़ने पर, FedCM माइग्रेशन की चेकलिस्ट का इस्तेमाल करके तैयारी करें.

एम्बेड किए गए कॉन्टेंट से उपयोगकर्ता का डेटा ऐक्सेस करना और उसमें बदलाव करना

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

उदाहरण के लिए, कोई उपयोगकर्ता website.example में लॉगिन कर सकता है, जो subscriptions.example विजेट को एम्बेड करता है. इस विजेट की मदद से, उपयोगकर्ता अपना डेटा मैनेज कर सकते हैं. जैसे, प्रीमियम कॉन्टेंट की सदस्यता लेना या बिलिंग की जानकारी अपडेट करना. उपयोगकर्ता के डेटा में बदलाव करने के लिए, हो सकता है कि एम्बेड किए गए विजेट को website.example पर एम्बेड करते समय, अपनी कुकी ऐक्सेस करनी पड़े. अगर यह डेटा website.example के लिए अलग से होना चाहिए, तो CHIPS की मदद से यह पक्का किया जा सकता है कि एम्बेड की गई जानकारी को ज़रूरत के हिसाब से ऐक्सेस किया जा सके. CHIPS की मदद से, website.example पर एम्बेड किए गए subscriptions.example विजेट के पास, अन्य वेबसाइटों पर उपयोगकर्ता की सदस्यता के डेटा का ऐक्सेस नहीं होगा.

एक और उदाहरण देखें: streaming.example का कोई वीडियो website.example पर एम्बेड किया गया है और उपयोगकर्ता के पास streaming.example की प्रीमियम सदस्यता है. विज्ञापनों को बंद करने के लिए, विजेट को इसकी जानकारी चाहिए. अगर एक ही कुकी को कई साइटों पर ऐक्सेस करना है, तो स्टोरेज ऐक्सेस एपीआई का इस्तेमाल करें. ऐसा तब करें, जब उपयोगकर्ता ने पहले streaming.example को टॉप-लेवल के तौर पर विज़िट किया हो. अगर website.example के सेट का मालिकाना हक streaming.example के पास है, तो मिलती-जुलती वेबसाइट के सेट का इस्तेमाल करें.

Chrome 131 से, FedCM को Storage Access API के साथ इंटिग्रेट किया गया है. इस इंटिग्रेशन की मदद से, जब उपयोगकर्ता FedCM प्रॉम्प्ट स्वीकार करेगा, तो ब्राउज़र आईडीपी को बिना बंटे हुए स्टोरेज का ऐक्सेस दे देगा.

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

फ़्रंट-चैनल लॉग आउट

फ़्रंट-चैनल लॉग आउट एक ऐसा तरीका है जिसकी मदद से, उपयोगकर्ता किसी एक सेवा से लॉग आउट करने पर, उससे जुड़े सभी ऐप्लिकेशन से लॉग आउट कर सकता है. OIDC के फ़्रंट-चैनल लॉग आउट के लिए, आईडीपी को कई भरोसेमंद पार्टी (आरपी) iframe एम्बेड करने होते हैं. ये iframe, आरपी की कुकी पर निर्भर होते हैं.

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

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

उपयोगकर्ता की अन्य गतिविधियां

तीसरे पक्ष की कुकी पर निर्भर न होने वाली उपयोगकर्ता यात्राओं पर, तीसरे पक्ष की कुकी को मैनेज करने के Chrome के तरीके में हुए बदलावों का असर नहीं पड़ेगा. पहले पक्ष के संदर्भ में, साइन इन, साइन आउट या खाता वापस पाने जैसे मौजूदा समाधान, दो-फ़ैक्ट ऑथेंटिकेशन के साथ सही तरीके से काम करने चाहिए. पहले ही, ब्रेक होने की संभावित जगहों के बारे में बताया गया है. किसी खास एपीआई के बारे में ज़्यादा जानकारी के लिए, एपीआई का स्टेटस पेज देखें. किसी भी तरह की गड़बड़ी की शिकायत करने के लिए, goo.gle/report-3pc-broken पर जाएं. सुझाव/राय, शिकायत या राय देने वाला फ़ॉर्म सबमिट किया जा सकता है. इसके अलावा, GitHub पर Privacy Sandbox के डेवलपर सहायता रिपॉज़िटरी में जाकर, समस्या की शिकायत भी की जा सकती है.

अपनी साइट का ऑडिट करना

अगर आपकी वेबसाइट, इस गाइड में बताई गई उपयोगकर्ता यात्राओं में से किसी एक को लागू करती है, तो आपको पक्का करना होगा कि आपकी साइटें तैयार हैं: तीसरे पक्ष की कुकी के इस्तेमाल के लिए अपनी साइट का ऑडिट करें, ब्रेकेज की जांच करें, और सुझाए गए समाधानों पर ट्रांज़िशन करें.