अपनी साइट को सेगमेंट में बांटी गई कुकी में ले जाते समय, किसी क्लाइंट के लिए एक ही नाम वाली पार्टिशन्ड और बिना पार्टी वाली कुकी मौजूद होने पर, आपको अनचाहे नतीजे मिल सकते हैं.
पार्टिशन्ड कुकी को सेट करने से, बिना किसी बांटी गई मौजूदा कुकी को उसी नाम से न तो बदला जाता है और न ही बदला जाता है. तीसरे पक्ष की कुकी के चालू रहने तक, दोनों का इस्तेमाल अलग-अलग कुकी जार में किया जाएगा. जब तीसरे पक्ष की कुकी बंद होती हैं, तो सिर्फ़ सेगमेंट में बांटी गई कुकी स्वीकार की जाएंगी. अगर दोनों कुकी मौजूद हैं, तो प्रोग्राम के ज़रिए यह नहीं बताया जा सकता है कि किस कुकी का बंटवारा किया गया है और किस कुकी को बांटा नहीं गया है. इससे ऐसा व्यवहार हो सकता है जिसकी वजह से कॉन्टेंट में उम्मीद से ज़्यादा अंतर हो.
इसे ठीक करने के दो विकल्प हैं: 1. जिस कुकी को बदलना है उसे खत्म करें 2. अपनी कुकी के नाम बदलें
ज़रूरी बातें
सेगमेंट में बांटी गई कुकी पर ट्रांज़िशन करते समय, इन बातों का ध्यान रखें:
- प्रोग्राम के हिसाब से यह पता लगाने का कोई तरीका नहीं है कि कुकी को बांटा गया है या बांटा नहीं गया है. हालांकि, Chrome DevTools में कुकी के बंटवारे की स्थिति का पता लगाया जा सकता है.
- बांटी गई कुकी, अलग-अलग कुकी को ओवरराइट नहीं करती हैं. अगर सिर्फ़ किसी एक के पास
Partitionedएट्रिब्यूट है, तो उन दो कुकी को अलग-अलग कुकी माना जाएगा जो बिलकुल एक जैसी होती हैं (यानी, नाम, डोमेन या पाथ जैसे एट्रिब्यूट एक जैसी होती हैं). - ऐसी स्थिति से बचना बेहतर होगा, जब एक ही नेटवर्क कॉल में एक ही नाम से सेगमेंट में बांटी गई कुकी और अलग-अलग कुकी दोनों हो.
बदली जा रही कुकी की समय-सीमा खत्म करें
अगर आपकी साइट या सेवा के नाम में बदलाव नहीं किया जा सकता, तो पार्टिशन की गई मौजूदा कुकी की समयसीमा खत्म होने के दौरान, नई पार्टिशन्ड कुकी बनाई जा सकती है. हालांकि, यह पता करने का कोई तरीका नहीं है कि कुकी को बांटा जाए या नहीं. हालांकि, बिना Partitioned एट्रिब्यूट वाले Set-Cookie हेडर, उन कुकी पर असर नहीं डालेंगे जिन्हें बांटा नहीं गया है.
इस उदाहरण में, example नाम की कुकी के अलग-अलग हिस्सों को खत्म करने का तरीका बताया गया है. साथ ही, उन कुकी को रहने दें जिन पर कोई असर न हुआ हो, भले ही उनका नाम एक ही हो. अगर पहले से ही cookieName नाम की एक अलग कुकी मौजूद है, तो उसे जोड़ा या अपडेट किया जाएगा.
Set-Cookie: example=-1;HttpOnly;SameSite=None;Secure;Max-Age:0
Set-Cookie: cookieName=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
अपनी कुकी के नाम बदलें
सेगमेंट को आसान बनाने के लिए, सेगमेंट में बांटी गई और अलग-अलग कुकी के लिए अलग-अलग नाम इस्तेमाल करना, इसका सबसे मज़बूत तरीका होता है. उदाहरण के लिए, अगर आपके पास "example" नाम की एक अलग कुकी है, तो उसे पार्टिशन्ड कुकी में माइग्रेट किया जा सकता है.
Set-Cookie: example-partitioned=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
कुकी के खत्म होने की तारीख को प्रोग्राम के हिसाब से नहीं दिखाया जाता है. इसलिए, ऐसा कोई तरीका नहीं है जिससे नई कुकी की समयसीमा तय की जा सके और उसे अलग-अलग कुकी की समयसीमा के तौर पर सेट किया जा सके. इस प्रोसेस के दौरान, कुकी की वैल्यू को रीफ़्रेश करना व्यावहारिक हो सकता है.
पार्टिशन्ड और अनपार्टिशन्ड, दोनों तरह की कुकी को बनाए रखना
ट्रांज़िशन की अवधि के दौरान, दो अलग-अलग सिंक की गई कुकी को बनाए रखें:
एक कुकी को बांटा गया हो और दूसरी को नहीं. उदाहरण के लिए, आपके पास auth और auth-partitioned, दोनों कुकी हो सकती हैं. इनमें बाद वाली कुकी को Partitioned एट्रिब्यूट के साथ सेट किया गया था.
हर बार वैल्यू अपडेट होने पर, आपको दोनों कुकी सेट करने की कोशिश करनी चाहिए.
- ऐसे क्लाइंट जो तीसरे पक्ष की कुकी ब्लॉक करते हैं, लेकिन अभी तक CHIPS के साथ काम नहीं करते: दोनों में से कोई भी कुकी स्वीकार नहीं की जाएगी.
- तीसरे पक्ष की कुकी ब्लॉक करने वाले और सीएचआईपीएस के साथ काम करने वाले क्लाइंट के लिए:
authकुकी अस्वीकार कर दी जाएगी, लेकिनauth-partitionedकुकी को स्वीकार किया जाएगा. - जो क्लाइंट तीसरे पक्ष की कुकी को ब्लॉक नहीं करते, चाहे वे सीएचआईपीएस के साथ काम करते हों या नहीं:
authऔरauth-partitioned, दोनों को स्वीकार किया जाता है.
जब आपके ऐप्लिकेशन को ऑथेंटिकेशन कुकी को पढ़ने की ज़रूरत हो, तो पहले आपको auth-partitioned खोजना चाहिए; लेकिन अगर आपको बदलाव को कुछ समय के लिए रोल बैक करना है, तो auth कुकी को आसानी से ढूंढें.
जब आपको यह पता चल जाए कि ज़्यादातर उपयोगकर्ताओं ने अपनी कुकी रीफ़्रेश कर ली हैं, तब auth-partitioned कुकी को बंद किया जा सकता है और
सेगमेंट में रखे गए एट्रिब्यूट को सामान्य पुष्टि करने वाली कुकी में जोड़ा जा सकता है.