ब्राउज़र की पाबंदियों, उपयोगकर्ता की सेटिंग, डेवलपर फ़्लैग या कंपनी की नीति की वजह से, तीसरे पक्ष की कुकी ब्लॉक की जा सकती हैं.
आपको अपनी साइट या सेवा से सभी उपयोगकर्ताओं को बेहतरीन अनुभव देना है. भले ही, तीसरे पक्ष की कुकी उपलब्ध हों या न हों.
इस पेज पर, आपको पहचान से जुड़े उन संभावित मामलों के बारे में जानकारी मिलेगी जिन पर असर पड़ सकता है. साथ ही, आपको संभावित समाधानों के बारे में भी जानकारी मिलेगी.
अगर आपकी वेबसाइट सिर्फ़ एक ही डोमेन और सबडोमेन में फ़्लो मैनेज करती है, जैसे कि publisher.example और login.publisher.example, तो वह क्रॉस-साइट कुकी का इस्तेमाल नहीं करेगी. साथ ही, तीसरे पक्ष की कुकी में हुए बदलावों का असर, आपके साइन-इन फ़्लो पर नहीं पड़ेगा.
हालांकि, अगर आपकी साइट पर लॉगिन करने के लिए किसी अलग डोमेन का इस्तेमाल किया जाता है, जैसे कि Google से साइन इन करें या Facebook से लॉगिन करें. इसके अलावा, अगर आपकी साइट को कई डोमेन या सबडोमेन पर उपयोगकर्ता की पुष्टि करने की जानकारी शेयर करनी है, तो आपको अपनी साइट में बदलाव करने पड़ सकते हैं. इससे यह पक्का किया जा सकेगा कि क्रॉस-साइट कुकी से आसानी से स्विच किया जा सके.
उपयोगकर्ताओं की सामान्य गतिविधियां
पहले, पहचान से जुड़े कई वर्कफ़्लो, तीसरे पक्ष की कुकी पर निर्भर होते थे. इस टेबल में, उपयोगकर्ता के कुछ सामान्य चरणों और उनके संभावित समाधानों के बारे में बताया गया है. ये समाधान, तीसरे पक्ष की कुकी पर निर्भर नहीं करते. इन सुझावों के पीछे की वजहों के बारे में, यहां बताया गया है.
इस्तेमाल के सामान्य उदाहरणों के लिए, सुझाए गए अन्य एपीआई
टेबल में दी गई सुविधाएं, डेवलपमेंट के शुरुआती चरणों में हैं. आपके सुझाव/राय या शिकायत से, उन्हें आने वाले समय में बेहतर काम करने में मदद मिलेगी. इन एपीआई के बारे में अपने सुझाव/राय दें: पार्टिशन किए गए पॉप-इन.
| उपयोगकर्ता की गतिविधि | सुझाए गए एपीआई |
|---|---|
| सोशल मीडिया से जुड़े खाते से साइन-इन करना |
पहचान की पुष्टि करने वाली सेवाओं के लिए: FedCM लागू करें भरोसेमंद पक्षों के लिए: पहचान की पुष्टि करने वाली सेवा से संपर्क करें |
|
आइडेंटिटी प्रोवाइडर या कस्टम समाधानों के लिए: मिलती-जुलती वेबसाइट के सेट |
|
| उपयोगकर्ता की प्रोफ़ाइल मैनेज करना |
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
| पुष्टि करना |
Storage Access API FedCM Web Authentication API scienceपार्टिशन किए गए पॉप-इन |
| आम तौर पर, इन स्थितियों में तीसरे पक्ष की कुकी पर निर्भरता नहीं होती है. इसलिए, इन पर कोई असर नहीं पड़ेगा. |
पहचान से जुड़ी उपयोगकर्ता की गतिविधियों को टेस्ट करना
यह जांच करने का सबसे अच्छा तरीका है कि तीसरे पक्ष की कुकी में हुए बदलावों का असर आपके साइन-इन फ़्लो पर पड़ा है या नहीं. इसके लिए, तीसरे पक्ष की कुकी की जांच करने वाले फ़्लैग को चालू करके रजिस्ट्रेशन, पासवर्ड वापस पाने, साइन-इन, और साइन-आउट फ़्लो को पूरा करें.
तीसरे पक्ष की कुकी पर पाबंदी लगाने के बाद, इन चीज़ों की जाँच करें:
- उपयोगकर्ता का रजिस्ट्रेशन: नया खाता बनाने की सुविधा ठीक से काम कर रही है. अगर तीसरे पक्ष की पहचान की पुष्टि करने वाली कंपनियों का इस्तेमाल किया जा रहा है, तो पक्का करें कि नए खातों का रजिस्ट्रेशन हर इंटिग्रेशन के लिए काम करता हो.
- पासवर्ड वापस पाना: पासवर्ड वापस पाने की सुविधा ठीक से काम कर रही है. जैसे, वेब यूज़र इंटरफ़ेस (यूआई) से लेकर CAPTCHA तक और पासवर्ड वापस पाने का ईमेल पाने तक.
- साइन-इन: साइन-इन करने का वर्कफ़्लो, एक ही डोमेन में और दूसरे डोमेन पर नेविगेट करते समय काम करता है. साइन इन करने की सुविधा के हर इंटिग्रेशन की जांच करना न भूलें.
- साइन-आउट: साइन-आउट करने की प्रोसेस सही तरीके से काम करती है. साथ ही, साइन-आउट करने के बाद उपयोगकर्ता साइन आउट रहता है.
आपको यह भी टेस्ट करना चाहिए कि उपयोगकर्ता के साइन इन करने की सुविधा देने वाली अन्य साइटें, क्रॉस-साइट कुकी के बिना काम कर रही हैं या नहीं. खास तौर पर, अगर उनमें क्रॉस-साइट रिसॉर्स लोड करने की सुविधा शामिल है. उदाहरण के लिए, अगर उपयोगकर्ता की प्रोफ़ाइल इमेज लोड करने के लिए सीडीएन का इस्तेमाल किया जाता है, तो पक्का करें कि यह अब भी काम कर रहा हो. अगर आपके पास उपयोगकर्ता के अहम सफ़र हैं, जैसे कि साइन-इन करने के बाद चेकआउट करना, तो पक्का करें कि ये काम करते रहें.
साइन-इन करने के समाधान
इस सेक्शन में, आपको इस बारे में ज़्यादा जानकारी मिलेगी कि इन फ़्लो पर कैसे असर पड़ सकता है.
तीसरे पक्ष की सिंगल साइन ऑन (एसएसओ) सुविधा
तीसरे पक्ष के सिंगल साइन-इन (एसएसओ) की सुविधा की मदद से, कोई उपयोगकर्ता एक प्लैटफ़ॉर्म पर क्रेडेंशियल के एक सेट से पुष्टि कर सकता है. इसके बाद, उसे अपनी लॉगिन जानकारी फिर से डाले बिना कई ऐप्लिकेशन और वेबसाइटों को ऐक्सेस करने की सुविधा मिलती है. एसएसओ (SSO) समाधान को लागू करना काफ़ी मुश्किल होता है. इसलिए, कई कंपनियां तीसरे पक्ष की सेवा देने वाली कंपनी का समाधान इस्तेमाल करती हैं. इससे, एक से ज़्यादा ऑरिजिन के बीच साइन-इन की स्थिति शेयर की जा सकती है. उदाहरण के लिए, Okta, Ping Identity, Google Cloud IAM या Microsoft Entra ID.
अगर आपका समाधान, तीसरे पक्ष की सेवा देने वाली कंपनी पर निर्भर करता है, तो हो सकता है कि कुछ छोटे-मोटे बदलाव करने पड़ें. जैसे, लाइब्रेरी को अपग्रेड करना. सबसे अच्छा तरीका यह है कि आप सेवा देने वाली कंपनी से इस बारे में सलाह लें कि तीसरे पक्ष की कुकी पर निर्भरता, समाधान को कैसे प्रभावित करती है. साथ ही, यह भी जानें कि वे अपनी सेवा के लिए किस तरीके का सुझाव देते हैं. कुछ प्रोवाइडर, तीसरे पक्ष की कुकी का इस्तेमाल बंद कर देंगे. ऐसे में, रिलाइंग पार्टियों को अपडेट करने की ज़रूरत नहीं होगी.
अनेक डोमेन
कुछ वेबसाइटें, सिर्फ़ उन उपयोगकर्ताओं की पुष्टि करने के लिए किसी दूसरे डोमेन का इस्तेमाल करती हैं जो एक ही साइट वाली कुकी के लिए ज़रूरी शर्तें पूरी नहीं करते. जैसे, कोई वेबसाइट मुख्य साइट के लिए example.com और लॉगिन फ़्लो के लिए login.example का इस्तेमाल करती है. इसके लिए, तीसरे पक्ष की कुकी को ऐक्सेस करने की ज़रूरत पड़ सकती है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता की पुष्टि दोनों डोमेन पर हो गई है.
कुछ कारोबारों के पास अलग-अलग डोमेन या सबडोमेन पर होस्ट किए गए कई प्रॉडक्ट हो सकते हैं. ऐसा हो सकता है कि ये समाधान, उपयोगकर्ता के सेशन को उन सभी प्रॉडक्ट के साथ शेयर करना चाहें. इस स्थिति में, एक से ज़्यादा डोमेन के बीच तीसरे पक्ष की कुकी को ऐक्सेस करने की ज़रूरत पड़ सकती है.
इस स्थिति में माइग्रेट करने के ये तरीके उपलब्ध हैं:
- पहले-पक्ष ("एक ही साइट") की कुकी का इस्तेमाल करने के लिए अपडेट करें: वेबसाइट के इन्फ़्रास्ट्रक्चर में बदलाव करें, ताकि लॉगिन फ़्लो को मुख्य साइट के डोमेन (या सबडोमेन) पर होस्ट किया जा सके. इससे सिर्फ़ पहले-पक्ष की कुकी का इस्तेमाल किया जा सकेगा. बुनियादी ढांचे को सेट अप करने के तरीके के आधार पर, इसमें ज़्यादा मेहनत करनी पड़ सकती है.
- मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) और Storage Access API (एसएए) का इस्तेमाल करें: आरडब्ल्यूएस की मदद से, मिलती-जुलती वेबसाइटों के छोटे ग्रुप के बीच, क्रॉस-साइट कुकी का सीमित ऐक्सेस मिलता है. RWS की मदद से, Storage Access API के ज़रिए स्टोरेज ऐक्सेस करने का अनुरोध करते समय, उपयोगकर्ता को कोई प्रॉम्प्ट नहीं दिखता. इससे उन आरपी पर एसएसओ की अनुमति मिलती है जो IdP की तरह ही RWS में हैं. हालांकि, RWS सिर्फ़ कुछ डोमेन पर, दूसरी साइट की कुकी के ऐक्सेस की सुविधा देता है.
- Web Authentication API का इस्तेमाल करें: Web Authentication API की मदद से, भरोसा करने वाली पार्टियां (आरपी) मिलते-जुलते ऑरिजिन का एक सीमित सेट रजिस्टर कर सकती हैं. इन ऑरिजिन पर क्रेडेंशियल बनाए और इस्तेमाल किए जा सकते हैं.
- अगर आपको पांच से ज़्यादा जुड़े हुए डोमेन पर उपयोगकर्ताओं की पुष्टि करनी है, तो Federated Credentials Management (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 को बांटा गया है. साथ ही, यह top-level.example पर पहले पक्ष के कॉन्टेक्स्ट में सेट की गई कुकी को ऐक्सेस नहीं कर सकता.3-party-app.example
जब किसी उपयोगकर्ता को top-level.example से 3-party-app.example और फिर वापस 3-party-app.example पर रीडायरेक्ट किया जाता है, तब भी यही समस्या होती है. इस कुकी को 3-party-app.example साइट के पहले-पक्ष के कॉन्टेक्स्ट में लिखा जाता है. हालांकि, इसे बांटा जाता है और यह 3-party-app.example iframe में ऐक्सेस नहीं की जा सकती.
अगर उपयोगकर्ता ने टॉप-लेवल के कॉन्टेक्स्ट में एम्बेड किए गए ऑरिजिन पर विज़िट किया है, तो Storage Access API एक अच्छा विकल्प है.
हमारा सुझाव है कि आइडेंटिटी प्रोवाइडर, तीसरे पक्ष की कुकी पर भरोसा करने वाले सलूशन से माइग्रेट करने के लिए, FedCM API का इस्तेमाल करें. साथ ही, FedCM को पॉप-अप के बजाय एम्बेड किए गए कॉन्टेंट से कॉल किया जाए.
इस फ़्लो के लिए सुझाया गया एक और समाधान, पार्टिशन किए गए पॉप-इन, लागू किया जा रहा है.
सोशल मीडिया खातों से साइन-इन करने की सुविधा
Google से साइन इन करें, Facebook से लॉगिन करें, और Twitter से लॉगिन करें जैसे साइन-इन बटन से पता चलता है कि आपकी वेबसाइट, फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का इस्तेमाल कर रही है. फ़ेडरेट किए गए हर आइडेंटिटी प्रोवाइडर का अपना तरीका होगा.
अगर अब काम न करने वाली Google Sign-In JavaScript Platform Library का इस्तेमाल किया जा रहा है, तो पुष्टि करने और अनुमति देने के लिए, Google Identity Services की नई लाइब्रेरी पर माइग्रेट करने के बारे में जानकारी पाएं.
Google Identity Services की नई लाइब्रेरी का इस्तेमाल करने वाली ज़्यादातर साइटों ने, तीसरे पक्ष की कुकी पर निर्भरता खत्म कर दी है. ऐसा इसलिए, क्योंकि लाइब्रेरी, बिना किसी सूचना के FedCM का इस्तेमाल करने के लिए माइग्रेट हो जाएगी, ताकि यह काम कर सके. हमारा सुझाव है कि आप अपनी साइट की जांच करें. इसके लिए, तीसरे पक्ष की कुकी को बंद करने की प्रोसेस की जांच करने वाले फ़्लैग को चालू करें. साथ ही, अगर ज़रूरत हो, तो तैयारी करने के लिए FedCM पर माइग्रेट करने की चेकलिस्ट का इस्तेमाल करें.
एम्बेड किए गए कॉन्टेंट से उपयोगकर्ता के डेटा को ऐक्सेस करना और उसमें बदलाव करना
एम्बेड किए गए कॉन्टेंट का इस्तेमाल अक्सर उपयोगकर्ता के सफ़र के लिए किया जाता है. जैसे, उपयोगकर्ता की प्रोफ़ाइल या सदस्यता के डेटा को ऐक्सेस या मैनेज करना.
उदाहरण के लिए, कोई उपयोगकर्ता website.example में लॉग इन कर सकता है. यह subscriptions.example विजेट को एम्बेड करता है. इस विजेट की मदद से लोग अपना डेटा मैनेज कर सकते हैं. जैसे, प्रीमियम कॉन्टेंट की सदस्यता लेना या बिलिंग की जानकारी अपडेट करना. उपयोगकर्ता के डेटा में बदलाव करने के लिए, एम्बेड किए गए विजेट को अपनी कुकी ऐक्सेस करनी पड़ सकती हैं. ऐसा तब होता है, जब विजेट को website.example पर एम्बेड किया गया हो. अगर इस डेटा को website.example से अलग रखना है, तो CHIPS यह पक्का करने में मदद कर सकता है कि एम्बेड की गई चीज़ को ज़रूरी जानकारी मिल सके. CHIPS की मदद से, subscriptions.example
website.example पर एम्बेड किए गए विजेट को, अन्य वेबसाइटों पर उपयोगकर्ता के सदस्यता डेटा का ऐक्सेस नहीं मिलेगा.
एक और उदाहरण देखें: streaming.example का कोई वीडियो website.example पर एम्बेड किया गया है. साथ ही, उपयोगकर्ता के पास streaming.example की प्रीमियम सदस्यता है. विज्ञापनों को बंद करने के लिए, विजेट को इस बारे में पता होना चाहिए. अगर एक ही कुकी को कई साइटों पर ऐक्सेस करना है, तो Storage Access API का इस्तेमाल करें. ऐसा तब करें, जब उपयोगकर्ता ने पहले streaming.example को टॉप-लेवल के तौर पर विज़िट किया हो. साथ ही, अगर website.example का सेट, streaming.example का मालिक है, तो मिलती-जुलती वेबसाइट के सेट का इस्तेमाल करें.
Chrome 131 से, FedCM को Storage Access API के साथ इंटिग्रेट किया गया है. इस इंटिग्रेशन की मदद से, जब उपयोगकर्ता FedCM प्रॉम्प्ट को स्वीकार करता है, तो ब्राउज़र, IdP को अनपार्टिशन किए गए स्टोरेज का ऐक्सेस देता है.
एम्बेड किए गए कॉन्टेंट के साथ किसी उपयोगकर्ता के सफ़र को मैनेज करने के लिए, कौनसा एपीआई चुनना है, इस बारे में ज़्यादा जानने के लिए एम्बेड करने की गाइड देखें.
उपयोगकर्ता की अन्य गतिविधियां
उपयोगकर्ता के ऐसे सफ़र जिन पर तीसरे पक्ष की कुकी का असर नहीं पड़ता उन पर, Chrome के तीसरे पक्ष की कुकी को मैनेज करने के तरीके में हुए बदलावों का असर नहीं पड़ना चाहिए. मौजूदा समाधान, जैसे कि पहले पक्ष के कॉन्टेक्स्ट में साइन इन करना, साइन आउट करना या खाता वापस पाना, 2FA, ठीक से काम करना चाहिए. बदलावों से जुड़ी संभावित समस्याओं के बारे में पहले बताया जा चुका है. किसी एपीआई के बारे में ज़्यादा जानकारी के लिए, एपीआई की स्थिति वाला पेज देखें.
अपनी साइट का ऑडिट करना
अगर आपकी वेबसाइट पर इस गाइड में बताई गई उपयोगकर्ता यात्राओं में से किसी एक को लागू किया गया है, तो आपको यह पक्का करना होगा कि आपकी साइटें तैयार हैं: तीसरे पक्ष की कुकी के इस्तेमाल के लिए अपनी साइट की जांच करें, यह जांच करें कि कहीं कोई गड़बड़ी तो नहीं हो रही है, और सुझाए गए समाधानों पर स्विच करें.