Chrome, Firefox, Edge, और अन्य ब्राउज़र, आईईटीएफ़ के प्रस्ताव के हिसाब से अपने डिफ़ॉल्ट व्यवहार को बदल रहे हैं. इंक्रीमेंटल बेहतर कुकी की मदद से ये बदलाव किए जा सकते हैं:
- बिना
SameSite
एट्रिब्यूट वाली कुकी कोSameSite=Lax
माना जाता है. इसका मतलब है कि डिफ़ॉल्ट तौर पर, कुकी को सिर्फ़ पहले पक्ष के कॉन्टेक्स्ट तक सीमित रखना होता है. - क्रॉस-साइट इस्तेमाल की कुकी में,
SameSite=None; Secure
के बारे में बताना ज़रूरी है, ताकि तीसरे पक्ष के कॉन्टेक्स्ट में उसे शामिल किया जा सके.
अगर आपने अब तक ऐसा नहीं किया है, तो आपको तीसरे पक्ष की कुकी के लिए एट्रिब्यूट अपडेट करने चाहिए, ताकि आने वाले समय में उन्हें ब्लॉक न किया जाए.
क्रॉस-साइट या तीसरे पक्ष की कुकी के लिए इस्तेमाल के उदाहरण
ऐसे कई सामान्य इस्तेमाल और पैटर्न हैं जिनमें कुकी को तीसरे पक्ष के कॉन्टेक्स्ट में भेजने की ज़रूरत होती है. अगर इस्तेमाल के ये उदाहरण दिए गए हैं या उन पर निर्भर हैं, तो पक्का करें कि आप या सेवा देने वाली कंपनी अपनी कुकी अपडेट कर रही हो, ताकि सेवा सही तरीके से काम कर सके.
<iframe>
में मौजूद कॉन्टेंट
<iframe>
में दिखाई गई किसी दूसरी साइट का कॉन्टेंट, तीसरे पक्ष के संदर्भ में है. इस्तेमाल के स्टैंडर्ड उदाहरणों में ये शामिल हैं:
- दूसरी साइटों से शेयर किया गया कॉन्टेंट, जैसे कि वीडियो, मैप, कोड सैंपल, और सोशल मीडिया पोस्ट.
- पेमेंट, कैलेंडर, बुकिंग, और बुकिंग से जुड़ी सुविधाओं जैसी बाहरी सेवाओं के विजेट.
- सोशल मीडिया के बटन जैसे विजेट या धोखाधड़ी रोकने वाली सेवाएं, जो साफ़ तौर पर जानकारी नहीं देतीं
<iframes>
.
यहां कुकी का इस्तेमाल, सेशन की स्थिति को बनाए रखने, सामान्य प्राथमिकताओं को सेव करने, आंकड़े चालू करने या मौजूदा खाते वाले उपयोगकर्ताओं के कॉन्टेंट को उपयोगकर्ता के मुताबिक बनाने के लिए भी किया जा सकता है.
![ब्राउज़र विंडो का डायग्राम, जिसमें एम्बेड किए गए कॉन्टेंट का यूआरएल, पेज के यूआरएल से मेल नहीं खाता.](https://web.dev/static/articles/samesite-cookie-recipes/image/diagram-a-browser-window-809ed902fbce7.png?authuser=6&hl=hi)
वेब को आसानी से कंपोज़ किया जा सकता है. इसलिए, <iframes>
का इस्तेमाल, टॉप-लेवल या पहले-पक्ष में देखे गए कॉन्टेंट को एम्बेड करने के लिए भी किया जाता है. iframe में इस्तेमाल की गई साइट में दिखाई गई सभी कुकी को तीसरे पक्ष की कुकी माना जाता है. अगर आपको ऐसी साइटें बनानी हैं जिन्हें दूसरी साइटों से एम्बेड किया जाए और उन्हें काम करने के लिए कुकी की ज़रूरत है, तो आपको यह भी पक्का करना होगा कि उन्हें क्रॉस-साइट इस्तेमाल करने के लिए मार्क किया गया हो. अगर ऐसा नहीं किया जाता है, तो उन्हें भी बिना ऐक्सेस के इस्तेमाल किया जा सकता है.
सभी साइटों पर "असुरक्षित" अनुरोध
यहां "असुरक्षित" लग सकता है, लेकिन यह किसी भी ऐसे अनुरोध के बारे में बताता है जिसका मकसद स्थिति में बदलाव करना हो. वेब पर, ये मुख्य रूप से POST अनुरोध होते हैं. SameSite=Lax
के तौर पर मार्क की गई कुकी, सुरक्षित टॉप लेवल नेविगेशन पर भेजी जाती हैं, जैसे कि किसी लिंक पर क्लिक करके, किसी दूसरी साइट पर जाना. हालांकि, POST का इस्तेमाल करके किसी दूसरी साइट पर <form>
के सबमिशन जैसी चीज़ों में कुकी शामिल नहीं होती हैं.
![एक पेज से दूसरे पेज पर जाने वाले अनुरोध का डायग्राम.](https://web.dev/static/articles/samesite-cookie-recipes/image/diagram-a-request-moving-46b47373768e3.png?authuser=6&hl=hi)
इस पैटर्न का इस्तेमाल उन साइटों के लिए किया जाता है जो वापस लौटने से पहले कुछ कार्रवाई करने के लिए, उपयोगकर्ता को रिमोट सेवा पर रीडायरेक्ट कर सकती हैं. उदाहरण के लिए, तीसरे पक्ष के आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करना. उपयोगकर्ता के साइट छोड़ने से पहले, एक कुकी सेट की जाती है जिसमें एक ही इस्तेमाल वाला टोकन होता है. इससे यह उम्मीद की जाती है कि क्रॉस साइट अनुरोध जालसाज़ी (सीएसआरएफ़) के हमलों को कम करने के लिए, लौटने वाले अनुरोध पर इस टोकन की जांच की जा सकती है. अगर लौटने का अनुरोध POST के ज़रिए मिलता है, तो आपको कुकी को SameSite=None; Secure
के तौर पर मार्क करना होगा.
रिमोट रिसॉर्स
पेज पर मौजूद <img>
टैग या <script>
टैग जैसा कोई भी रिमोट रिसॉर्स, अनुरोध के साथ भेजी जा रही कुकी पर निर्भर हो सकता है. सामान्य इस्तेमाल के उदाहरणों में ट्रैकिंग पिक्सल और
कॉन्टेंट को उपयोगकर्ता के हिसाब से बनाना शामिल है.
यह fetch
या
XMLHttpRequest
का इस्तेमाल करके आपके JavaScript से भेजे गए अनुरोधों पर भी लागू होता है. अगर fetch()
को credentials: 'include'
विकल्प के साथ कॉल किया जाता है, तो उन अनुरोधों में कुकी शामिल हो सकती हैं.
XMLHttpRequest
के लिए, अनुमानित कुकी को आम तौर पर true
के लिए withCredentials
वैल्यू से दिखाया जाता है. उन कुकी को क्रॉस-साइट अनुरोधों में शामिल करने के लिए सही तरीके से मार्क किया जाना चाहिए.
वेबव्यू में मौजूद कॉन्टेंट
प्लैटफ़ॉर्म के हिसाब से काम करने वाले ऐप्लिकेशन में वेबव्यू, ब्राउज़र से चलता है. डेवलपर को यह टेस्ट करना होगा कि उनके ऐप्लिकेशन पर असर डालने वाली पाबंदियां या समस्याएं, उनके ऐप्लिकेशन के वेबव्यू पर भी लागू होती हैं या नहीं.
Android, अपने प्लैटफ़ॉर्म के लिए खास ऐप्लिकेशन को सीधे CookieManager API का इस्तेमाल करके, कुकी सेट करने की अनुमति देता है.
हेडर या JavaScript का इस्तेमाल करके सेट की गई कुकी की तरह ही, अगर SameSite=None; Secure
को क्रॉस-साइट इस्तेमाल के लिए बनाया गया है, तो उसे शामिल करने के बारे में सोचें.
SameSite
को आज कैसे लागू करें
अपनी ज़रूरत के हिसाब से, उन कुकी को SameSite=Lax
या SameSite=Strict
के तौर पर मार्क करें जिनकी ज़रूरत सिर्फ़ पहले-पक्ष के लिए होती है. अगर इन कुकी को मार्क नहीं किया जाता है
और इन्हें मैनेज करने के लिए, ब्राउज़र के डिफ़ॉल्ट बिहेवियर पर निर्भर रहना पड़ता है, तो ये ब्राउज़र पर अलग-अलग तरह से काम कर सकती हैं.
साथ ही, हर कुकी के लिए कंसोल चेतावनियां भी ट्रिगर कर सकती हैं.
Set-Cookie: first_party_var=value; SameSite=Lax
तीसरे पक्ष के लिए ज़रूरी सभी कुकी को
SameSite=None; Secure
के तौर पर मार्क करना न भूलें. दोनों एट्रिब्यूट ज़रूरी हैं. अगर आपने Secure
के बिना None
तय किया है, तो कुकी अस्वीकार कर दी जाएगी. ब्राउज़र लागू करने के तरीकों में अंतर को समझने के लिए, आपको उन क्लाइंट को मैनेज करना जो काम नहीं करते में बताई गई कम करने वाली रणनीतियों का इस्तेमाल करना होगा.
Set-Cookie: third_party_var=value; SameSite=None; Secure
असंगत क्लाइंट को प्रबंधित करें
None
को शामिल करने और अपडेट करने का डिफ़ॉल्ट तरीका अब भी नए हैं. इसलिए, अलग-अलग ब्राउज़र इन्हें अलग-अलग तरीके से हैंडल करते हैं. आम तौर पर होने वाली समस्याओं की सूची देखने के लिए, chromium.org पर अपडेट वाले पेज पर जाएं. हालांकि, ऐसा हो सकता है कि इस सूची में सभी समस्याएं न हों.
इसका एक संभावित हल यह है कि आप हर कुकी को नई और पुरानी, दोनों शैली में सेट करें:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
नई कार्रवाई लागू करने वाले ब्राउज़र, कुकी को SameSite
वैल्यू के साथ सेट करते हैं. जो ब्राउज़र नई कार्रवाई को लागू नहीं करते हैं वे उस वैल्यू को अनदेखा कर देते हैं और 3pcookie-legacy
कुकी सेट कर देते हैं. शामिल की गई कुकी को प्रोसेस करते समय, आपकी साइट को पहले जांच करनी चाहिए कि कुकी की नई स्टाइल मौजूद है या नहीं. इसके बाद, अगर नई कुकी नहीं मिलती है, तो लेगसी कुकी पर वापस चला जाना चाहिए.
यहां दिए गए उदाहरण में, एक्सप्रेशन फ़्रेमवर्क और उसके cookie-parser मिडलवेयर का इस्तेमाल करके, Node.js में ऐसा करने का तरीका बताया गया है:
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
इस तरीके को अपनाने के लिए, आपको गै़र-ज़रूरी कुकी सेट करके अतिरिक्त काम करना पड़ता है. साथ ही, कुकी को सेट करने और पढ़ने के दौरान ही उनमें बदलाव करने पड़ते हैं. हालांकि, इसमें सभी ब्राउज़र को शामिल करना चाहिए, फिर चाहे वे काम कैसे भी करते हों और तीसरे पक्ष की कुकी सही तरीके से काम करती रहें.
इसके अलावा, उपयोगकर्ता एजेंट स्ट्रिंग का इस्तेमाल करके,
Set-Cookie
हेडर भेजे जाने पर क्लाइंट का पता लगाया जा सकता है. काम न करने वाले क्लाइंट की सूची देखें और अपने प्लैटफ़ॉर्म के लिए सही यूज़र एजेंट की पहचान करने वाली लाइब्रेरी का इस्तेमाल करें. उदाहरण के लिए, Node.js पर ua-parser-js लाइब्रेरी. इस तरीके में आपको सिर्फ़ एक बदलाव करना होगा, लेकिन हो सकता है कि उपयोगकर्ता एजेंट स्निफ़िंग उन सभी उपयोगकर्ताओं को न पकड़ पाए जिन पर असर हुआ है.
भाषाओं, लाइब्रेरी, और फ़्रेमवर्क में SameSite=None
के साथ काम करता है
ज़्यादातर भाषाओं और लाइब्रेरी में, कुकी के लिए SameSite
एट्रिब्यूट काम करता है. हालांकि, SameSite=None
जोड़ा गया है, लेकिन यह अब भी हाल ही का है. इसलिए, हो सकता है कि फ़िलहाल आपको स्टैंडर्ड तरीकों पर काम करना पड़े.
इन गतिविधियों के बारे में GitHub पर डेटा स्टोर करने की SameSite
उदाहरण में जानकारी दी गई है.
सहायता पाना
कुकी का इस्तेमाल वेब पर हर जगह होता है. किसी भी डेवलपमेंट टीम को शायद ही इस बात की पूरी जानकारी हो कि उनकी साइट कहां सेट है और उनका इस्तेमाल करती है. खास तौर पर, क्रॉस-साइट इस्तेमाल के मामलों में. जब आपको कोई समस्या आती है, तो हो सकता है कि वह पहली बार हो जिसका सामना किसी को भी हुआ हो, इसलिए हमसे बेझिझक संपर्क करें:
- GitHub पर
SameSite
उदाहरण वाले रिपॉज़िटरी में समस्या के बारे में बताएं. - StackOverflow पर"samesite" टैग में सवाल पूछें.
- Chromium के काम करने से जुड़ी समस्याओं के लिए, Chromium की समस्या को ट्रैक करने वाले टूल में जाकर गड़बड़ी की शिकायत करें.
SameSite
अपडेट पेज पर Chrome की प्रोग्रेस को फ़ॉलो करें.