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

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

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

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

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

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

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

टेबल में मौजूद सुविधाएं, डेवलपमेंट के शुरुआती चरणों में हैं. आपका सुझाव/राय/शिकायत हमारे लिए बहुत अहम है. इससे हमें आने वाले समय में इस सुविधा को बेहतर बनाने में मदद मिलेगी. इन एपीआई के बारे में अपने सुझाव दें: पार्टिशन किए गए पॉपिन.

उपयोगकर्ता की गतिविधि सुझाए गए एपीआई
सोशल साइन-इन आइडेंटिटी प्रोवाइडर के लिए: 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 का इस्तेमाल करने वाली वेबसाइट. इसके लिए, तीसरे पक्ष की कुकी को ऐक्सेस करना पड़ सकता है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता की पुष्टि दोनों डोमेन में की गई है.

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

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

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

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

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

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

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

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