इस पेज का अनुवाद Cloud Translation API से किया गया है.

SameSite कुकी रेसिपी

Rowan Merewood

ध्यान दें: यह पेज, SameSite कुकी एट्रिब्यूट में हुए बदलावों की सीरीज़ का हिस्सा है. इस सीरीज़ में ये शामिल हैं:

Chrome, Firefox, Edge, और अन्य ब्राउज़र, IETF के प्रस्ताव, बेहतर कुकी के मुताबिक अपने डिफ़ॉल्ट व्यवहार में बदलाव कर रहे हैं, ताकि:

SameSite एट्रिब्यूट के बिना कुकी को SameSite=Lax के तौर पर माना जाता है. इसका मतलब है कि डिफ़ॉल्ट रूप से, कुकी को सिर्फ़ पहले पक्ष के कॉन्टेक्स्ट तक सीमित रखा जाता है.
अलग-अलग साइटों पर इस्तेमाल की जाने वाली कुकी में SameSite=None; Secure की जानकारी होनी चाहिए, ताकि तीसरे पक्ष के संदर्भ में शामिल करने की सुविधा चालू की जा सके.

अगर आपने अब तक ऐसा नहीं किया है, तो आपको तीसरे पक्ष की कुकी के लिए एट्रिब्यूट अपडेट करने चाहिए, ताकि आने वाले समय में उन्हें ब्लॉक न किया जाए.

ब्राउज़र के इस्तेमाल से जुड़ी सहायता

सोर्स

अलग-अलग साइटों या तीसरे पक्ष की कुकी के इस्तेमाल के उदाहरण

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

`<iframe>` में मौजूद कॉन्टेंट

<iframe> में दिखने वाला किसी दूसरी साइट का कॉन्टेंट, तीसरे पक्ष के कॉन्टेक्स्ट में होता है. इस्तेमाल के सामान्य उदाहरणों में ये शामिल हैं:

एम्बेड किया गया ऐसा कॉन्टेंट जिसे दूसरी साइटों पर शेयर किया गया हो. जैसे, वीडियो, मैप, कोड सैंपल, और सोशल मीडिया पर पोस्ट किया गया कॉन्टेंट.
पेमेंट, कैलेंडर, बुकिंग, और रिज़र्वेशन जैसी सुविधाओं के लिए, बाहरी सेवाओं के विजेट.
सोशल मीडिया बटन या धोखाधड़ी रोकने वाली सेवाओं जैसे विजेट, जो ज़्यादा साफ़ तौर पर नहीं दिखते <iframes>.

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

ब्राउज़र विंडो का डायग्राम, जिसमें एम्बेड किए गए कॉन्टेंट का यूआरएल, पेज के यूआरएल से मेल नहीं खाता. — अगर एम्बेड किया गया कॉन्टेंट, टॉप-लेवल ब्राउज़िंग कॉन्टेक्स्ट वाली साइट से नहीं आता है, तो उसे तीसरे पक्ष का कॉन्टेंट माना जाता है.

वेब में कॉम्पोनेंट जोड़ने की सुविधा होती है. इसलिए, <iframes> का इस्तेमाल, टॉप-लेवल या पहले पक्ष के कॉन्टेक्स्ट में देखे गए कॉन्टेंट को एम्बेड करने के लिए भी किया जाता है. iframe में दिखाई गई साइट की किसी भी कुकी को तीसरे पक्ष की कुकी माना जाता है. अगर आपको ऐसी साइटें बनानी हैं जिन्हें अन्य साइटों पर एम्बेड किया जा सके और उन्हें काम करने के लिए कुकी की ज़रूरत है, तो आपको यह भी पक्का करना होगा कि उन्हें अलग-अलग साइटों पर इस्तेमाल करने के लिए मार्क किया गया हो या उनके बिना भी साइटें काम कर सकें.

सभी साइटों पर "असुरक्षित" अनुरोध

"असुरक्षित" शब्द यहां परेशान करने वाला लग सकता है, लेकिन इसका मतलब किसी ऐसे अनुरोध से है जिसका मकसद स्थिति बदलना हो. वेब पर, ये मुख्य तौर पर POST अनुरोध होते हैं. SameSite=Lax के तौर पर मार्क की गई कुकी, सुरक्षित टॉप-लेवल नेविगेशन पर भेजी जाती हैं. जैसे, किसी दूसरी साइट पर जाने के लिए लिंक पर क्लिक करना. हालांकि, POST का इस्तेमाल करके किसी दूसरी साइट पर <form> सबमिशन करने जैसी चीज़ में कुकी शामिल नहीं होती हैं.

एक पेज से दूसरे पेज पर जाने वाले अनुरोध का डायग्राम. — अगर आने वाला अनुरोध "सुरक्षित" तरीके का इस्तेमाल करता है, तो पेज कुकी भेजता है.

इस पैटर्न का इस्तेमाल उन साइटों के लिए किया जाता है जो उपयोगकर्ता को किसी रिमोट सेवा पर रीडायरेक्ट कर सकती हैं, ताकि वह वापस आने से पहले कोई कार्रवाई कर सके. उदाहरण के लिए, तीसरे पक्ष के आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करना. उपयोगकर्ता के साइट छोड़ने से पहले, एक बार इस्तेमाल होने वाले टोकन वाली कुकी सेट की जाती है. ऐसा इसलिए किया जाता है, ताकि दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीएसआरएफ़) वाले हमलों को कम करने के लिए, वापस आने वाले अनुरोध पर इस टोकन की जांच की जा सके. अगर वह अनुरोध 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 कुकी सेट कर देते हैं. शामिल की गई कुकी को प्रोसेस करते समय, आपकी साइट को सबसे पहले यह देखना चाहिए कि कुकी का नया स्टाइल मौजूद है या नहीं. अगर उसे नया स्टाइल नहीं मिलता है, तो वह लेगसी कुकी का इस्तेमाल करती है.

नीचे दिए गए उदाहरण में, Express फ़्रेमवर्क और उसके 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 के अपडेट की स्थिति देखें.