SameSite कुकी रेसिपी

Rowan Merewood

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

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

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

क्रॉस-ब्राउज़र सहायता

एमडीएन के Set-Cookie पेज पर ब्राउज़र के साथ काम करने की सुविधा सेक्शन देखें.

क्रॉस-साइट या तीसरे पक्ष की कुकी के लिए इस्तेमाल के उदाहरण

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

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

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

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

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

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

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

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

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

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

इस पैटर्न का इस्तेमाल उन साइटों के लिए किया जाता है जो लौटने से पहले कुछ कार्रवाई करने के लिए, उपयोगकर्ता को रिमोट सेवा पर रीडायरेक्ट कर सकती हैं. उदाहरण के लिए, तीसरे पक्ष के आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करना. उपयोगकर्ता के साइट छोड़ने से पहले, एक कुकी सेट की जाती है जिसमें एक ही बार इस्तेमाल किया जा सकने वाला टोकन होता है. इस कुकी को यह उम्मीद के साथ सेट किया जाता है कि वापस आने वाले अनुरोध पर इस टोकन की जांच की जा सकती है, ताकि क्रॉस साइट अनुरोध जालसाज़ी (सीएसआरएफ़) के हमलों को कम किया जा सके. अगर लौटने वाला वह अनुरोध POST के ज़रिए मिलता है, तो कुकी को SameSite=None; Secure के तौर पर मार्क करना ज़रूरी होगा.

रिमोट रिसॉर्स

ऐसा हो सकता है कि किसी पेज पर मौजूद कोई भी रिमोट रिसॉर्स, <img> टैग, <script> टैग वगैरह के अनुरोध के साथ भेजी जाने वाली कुकी पर निर्भर हो. सामान्य इस्तेमाल के उदाहरणों में ट्रैकिंग पिक्सल और कॉन्टेंट को उपयोगकर्ता के हिसाब से बनाना शामिल है.

यह fetch या XMLHttpRequest से आपके JavaScript से किए गए अनुरोधों पर भी लागू होता है. अगर fetch() को credentials: 'include' विकल्प के साथ कॉल किया जाता है, तो इसका मतलब है कि ऐसे अनुरोधों के लिए कुकी की उम्मीद की जा सकती है. XMLHttpRequest के लिए, आपको withCredentials प्रॉपर्टी के उन इंस्टेंस को देखने चाहिए जिन्हें true पर सेट किया गया है. यह इस बात का अच्छा संकेत है कि उन अनुरोधों पर कुकी की उम्मीद की जा सकती है. इन कुकी को क्रॉस-साइट अनुरोधों में शामिल करने के लिए सही तरीके से मार्क करना होगा.

वेबव्यू में मौजूद कॉन्टेंट

प्लैटफ़ॉर्म के हिसाब से काम करने वाले ऐप्लिकेशन में वेबव्यू को किसी ब्राउज़र से चलाया जाता है. ऐसे में, आपको यह जांच करनी होगी कि क्या वही पाबंदियां या समस्याएं लागू होती हैं. Android में, अगर वेबव्यू Chrome पर काम करता है, तो Chrome 84 में नए डिफ़ॉल्ट तुरंत लागू नहीं होंगे. हालांकि, हमारा मकसद इन्हें आने वाले समय में लागू करना है, इसलिए आपको अभी भी इसकी जांच करनी चाहिए और इसके लिए तैयार रहना चाहिए. इसके अलावा, 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 कुकी को सेट करेंगे. शामिल की गई कुकी को प्रोसेस करते समय, साइट को सबसे पहले यह जांच करनी चाहिए कि नई स्टाइल कुकी मौजूद है या नहीं. अगर कुकी नहीं मिलती है, तो पुरानी कुकी पर वापस लौटनी चाहिए.

नीचे दिए गए उदाहरण में, Node.js में ऐसा करने का तरीका बताया गया है. साथ ही, इसमें एक्सप्रेस फ़्रेमवर्क और इसके cookie-parser मिडलवेयर का इस्तेमाल किया गया है.

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 रेपो के रेपो में बताया गया है.

सहायता पाना

कुकी हर जगह मौजूद हैं और ऐसा बहुत कम होता है कि किसी साइट ने उन्हें सेट किए जाने और इस्तेमाल किए जाने की पूरी तरह से जांच की हो. ऐसा खास तौर पर तब होता है, जब अलग-अलग तरह की कुकी के बारे में बात की जाती है. जब आपको कोई समस्या होती है, तो हो सकता है कि कोई भी व्यक्ति पहली बार इस समस्या का सामना कर रहा हो, इसलिए हमसे बेझिझक संपर्क करें: