कुकी क्या है? HTTP राज्य, सुरक्षा और सहमति

कुकी क्या है?

Scrapeless Agent Browser स्वीकृत नेविगेशन वर्कफ़्लो के लिए कुकी स्थिति बनाए रख सकता है।

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

कुकीज़ वायर स्तर पर सरल होती हैं लेकिन अनुप्रयोगों और स्वचालन में गलत तरीके से प्रबंधित करना आसान होता है। एक संग्रहीत सत्र उपयोगी हो सकता है; यह एक खाता को उजागर भी कर सकता है यदि इसे गलत वातावरण में कॉपी किया जाता है। यह गाइड एक कुकी को सर्वर के उत्तर से लेकर बाद के अनुरोध तक का अनुसरण करता है और महत्वपूर्ण सीमाओं को समझाता है।

एक ब्राउज़र कैसे कुकी प्राप्त करता है और भेजता है

एक सर्वर एक Set-Cookie प्रतिक्रिया हेडर भेज सकता है। ब्राउज़र निर्णय लेता है कि क्या कुकी को stated विशेषताओं के तहत संग्रहित करना है। भविष्य के अनुरूप अनुरोधों पर, ब्राउज़र एक कुकी अनुरोध हेडर में लागू कुकीज़ को शामिल करता है। MDN कुकी गाइड इस विनिमय और मुख्य संग्रहण और दायरा व्यवहार का वर्णन करता है।

एक कुकी को हर गंतव्य पर स्वचालित रूप से नहीं भेजा जाता है। होस्ट, डोमेन, पथ, सुरक्षित, और SameSite नियम पात्रता को प्रभावित करते हैं। ब्राउज़र गोपनीयता सेटिंग्स और समाप्ति भी महत्वपूर्ण हो सकती हैं। जब एक अनुरोध लॉगिन स्थिति को खोता हुआ प्रतीत होता है, तो यह जांचें कि क्या ब्राउज़र ने सर्वर द्वारा सत्र को छोड़ने का अनुमान लगाने से पहले अपेक्षित कुकी भेजी थी।

सर्वर को प्राप्त नाम और मूल्य का अर्थ निकालना चाहिए। एक सत्र पहचानकर्ता सर्वर को खाता स्थिति को खोजने की अनुमति दे सकता है, लेकिन केवल कुकी यह नहीं बताती कि वह सत्र अभी भी मान्य है या नहीं। एक साइट एक सत्र को रद्द कर सकती है या पुनर्नविकृत प्रमाणीकरण की आवश्यकता कर सकती है। सफल ब्राउज़र स्टोरेज ऑपरेशन यह नहीं बताता कि सर्वर अगला अनुरोध स्वीकार करेगा।

कुकी दायरा और जीवनकाल

डोमेन नियंत्रित करता है कि कौन सा होस्ट या उपडोमेन कुकी प्राप्त कर सकता है, जबकि पथ उन अनुरोध पथों को प्रतिबंधित करता है जिनके लिए इसे भेजा जाता है। एक होस्ट-केवल कुकी एक जानबूझकर साझा की गई उपडोमेन के साथ तुलना में संकीर्ण होती है। Set-Cookie संदर्भ विवरण बताता है कि ये विशेषताएँ कैसे व्याख्यायित की जाती हैं। एक पथ मान एक भेजने का नियम है, न कि सभी कोड से मूल्य की सुरक्षा करने वाली एक सुरक्षा सीमा।

समयावधि को Max-Age या Expires के साथ व्यक्त किया जा सकता है। स्थायी जीवनकाल की जानकारी के बिना, एक कुकी सामान्यतः एक सत्र कुकी होती है, हालांकि ब्राउज़र सत्र बहाली इस पर प्रभाव डाल सकती है कि यह कब गायब होती है। एक अनुप्रयोग को यह मानने की ज़रूरत नहीं है कि हर ब्राउज़र एक पूर्वानुमानित क्षण में बंद हो जाता है। सर्वर-साइड सत्र का जीवनकाल एक स्वतंत्र निर्णय बना रहता है।

एक कुकी को प्रतिस्थापित करने के लिए, एक सर्वर आमतौर पर मिलते-जुलते नाम और दायरे के साथ एक नया मान भेजता है। इसे हटाने के लिए, सर्वर संगत दायरे के साथ एक समाप्त मान सेट कर सकता है। केवल एक दिखने वाली कुकी को साफ़ करने वाला एक डेवलपर एक अलग पथ या डोमेन के साथ एक अन्य विविधता छोड़ सकता है। कुकी नाम से मात्र अनुमान लगाने के बजाय पूर्ण दायरे और प्रतिक्रिया इतिहास को डिबग करें।

सुरक्षा विशेषताएँ और उनके सीमाएँ

सुरक्षित ब्राउज़र को सुरक्षित कनेक्शनों के माध्यम से कुकी भेजने के लिए बताता है। HttpOnly सामान्य पृष्ठ JavaScript को इसे document.cookie के माध्यम से पढ़ने से रोकता है, स्क्रिप्ट इंजेक्शन से टोकन चोरी के लिए एक मार्ग को कम करता है। SameSite क्रॉस-साइट स्थितियों में भेजने को नियंत्रित करता है और कुछ अनुरोध-धोखाधड़ी के जोखिम को कम करने में मदद कर सकता है। MDN सुरक्षित-कुकी मार्गदर्शन कुकी के उद्देश्य के अनुसार सख्त सेटिंग्स की सिफारिश करता है।

ये विशेषताएँ विभिन्न खतरों का सामना करती हैं। HttpOnly ब्राउज़र को पात्र अनुरोधों के साथ कुकी भेजने से नहीं रोकता है। सुरक्षित अपने मूल्य द्वारा निर्दिष्ट खाते को अधिकृत नहीं करता है। SameSite प्रत्येक अनुप्रयोग डिजाइन के लिए एक पूर्ण अनुरोध-धोखाधड़ी रक्षा को प्रतिस्थापित नहीं करता है। सर्वर-साइड पहुंच जांच और सत्र अमान्यकरण कुकी के वितरित होने के बाद भी महत्वपूर्ण होते हैं।

उदाहरणों, लॉग, या समर्थन टिकटों में असली सत्र कुकीज़ कभी न प्रकाशित करें। एक सत्र टोकन पहुंच प्रदान कर सकता है भले ही इसके वर्ण निरर्थक दिखते हों। अनुरोध trace कैप्चर करते समय मानों को मिटा दें, और केवल वे नाम और विशेषताएँ रखें जो व्यवहार का निदान करने के लिए आवश्यक हैं। यदि ब्राउज़र प्रोफ़ाइल भंडारण में प्रमाणित स्थिति शामिल है, तो इसे संवेदनशील मानें।

कुकीज़, CORS, और क्रॉस-साइट अनुरोध

क्रॉस-साइट अनुरोधों में कुकी नीति और ब्राउज़र प्रतिक्रिया-पढ़ने की नीति दोनों शामिल होती हैं। SameSite एक अनुरोध से कुकी को दूर रख सकता है, जबकि CORS पृष्ठ स्क्रिप्ट को प्रतिक्रिया पढ़ने से रोक सकता है। ये अलग जांच हैं। एक सर्वर सही CORS हेडर वापस कर सकता है और फिर भी एक अनधिकृत कॉलर देख सकता है क्योंकि कोई सत्र कुकी नहीं भेजी गई थी।

SameSite=None वाली कुकी को वर्तमान ब्राउज़र नियमों के तहत सुरक्षित होना आवश्यक है। प्रमाणित क्रॉस-उद्देश्य फेच को भी एक उपयुक्त अनुरोध क्रेडेंशियल मोड और मेल खाता सर्वर CORS प्रतिक्रिया की आवश्यकता होती है। ब्राउज़र उन सेटिंग्स का अनुमान नहीं लगाता है क्योंकि एक कुकी मौजूद है। जब एक एकीकरण एक सीधे HTTP क्लाइंट में काम करता है लेकिन ब्राउज़र में विफल होता है, तो वास्तविक पृष्ठ मूल और लक्ष्य का परीक्षण करें, जिसमें रीडायरेक्ट शामिल हैं।

तृतीय-पक्ष कुकी सीमाएँ और ब्राउज़र सेटिंग्स परिणाम को और बदल सकती हैं। एक अपरिचित साइट से भेजी गई कुकी के चारों ओर एक महत्वपूर्ण वर्कफ़्लो डिज़ाइन करने से बचें जब तक कि वास्तुकला और ब्राउज़र समर्थन की जांच नहीं की गई हो। जब आप दोनों सिस्टम के मालिक होते हैं, तो एक सर्वर-साइड विनिमय या एक ही साइट का डिज़ाइन सुरक्षा मॉडल को सरल बना सकता है।

ब्राउज़र स्वचालन में कुकीज़

एक ब्राउज़र स्वचालन सत्र पृष्ठ क्रियाओं के बीच स्थिति ले जाता है। Scrapeless Agent Browser एक दूरस्थ ब्राउज़र वातावरण प्रदान करता है, और इसका दस्तावेज़ीकरण सत्र-आधारित संचालन का परिचय देता है। कुकीज़ एक स्वीकृत वर्कफ़्लो को संकेत में रखते हुए मदद कर सकती हैं जब यह पृष्ठों के बीच स्थानांतरित होती है। इन्हें स्वीकृत खाते और कार्य के लिए परिधि में होना चाहिए।

एक ताजा ब्राउज़र संदर्भ उपयोगी है जब किसी कार्य को दूसरे उपयोगकर्ता की स्थिति विरासत में नहीं लेनी चाहिए। एक स्थायी प्रोफ़ाइल उपयोगी है जब अधिकृत स्थिति को सत्रों के बीच जीवित रहना आवश्यक है, लेकिन यह पहुँच और संरक्षण के प्रश्न उठाती है। संबंधित ब्राउज़र प्रमाणीकरण गाइड चर्चा करता है कि लॉगिन स्थिति में कुकीज और अन्य भंडारण शामिल हो सकते हैं। यह मान लेना ठीक नहीं है कि एक कुकी को निर्यात करना पूरे सत्र को पुन: उत्पन्न करता है।

जब एक कार्यप्रवाह विभिन्न चलानों के बीच विभिन्न सामग्री देखता है, तो खाते, ब्राउज़र प्रोफ़ाइल, कुकी दायरा, अंतिम URL और किसी भी स्थान सेटिंग की तुलना करें। एक कुकी व्यक्तिगतकरण को प्रभावित कर सकती है, लेकिन एक लापता परिणाम पृष्ठ समय या एक पहुंच निर्णय से भी आ सकता है। अवलोकनों को अलग रखना निदान को पुनरुत्पादित बनाने और निजी सत्र सामग्री के अनावश्यक प्रबंधन से बचाने में मदद करता है।

गोपनीयता और व्यावहारिक कुकी डिज़ाइन

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

जिस सेवा का आप संचालन करते हैं, उसमें लॉगआउट, खाता स्विचिंग और क्रॉस-डिवाइस परिदृश्यों में कुकी व्यवहार का परीक्षण करें। ब्राउज़र से कुकी का गायब होना अनिवार्य रूप से एक सर्वर सत्र को अमान्य नहीं करता है। इसके विपरीत, एक समाप्त सर्वर सत्र एक संग्रहीत कुकी छोड़ सकता है जो अब पहुंच की अनुमति नहीं देता। दोनों स्तरों को एक सुसंगत जीवनचक्र की आवश्यकता होती है।

जिस सेवा का आप संचालन नहीं करते हैं, उसमें किसी अन्य व्यक्ति के कुकी मानों को एकत्रित करने या पुन: उपयोग करने से बचें। सार्वजनिक पृष्ठ निष्कर्षण में शायद ही कभी प्रमाणित स्थिति की आवश्यकता होती है। यदि एक अधिकृत कार्यप्रवाह लॉगिन की आवश्यकता करता है, तो उस खाते के नियंत्रण में प्रोफ़ाइल रखें और निर्यात किए गए डेटासेट या साझा निदान फ़ाइलों में टोकन मानों को रखने से बचें।

जब कुकी डिबगिंग को एक हेडर से अधिक की आवश्यकता होती है

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

यह भी जांचें कि क्या पृष्ठ अन्य ब्राउज़र भंडारण पर निर्भर करता है। स्थानीय भंडारण, सत्र भंडारण, और इन-मेमोरी टोकन कुकीज़ से अलग नियमों का पालन करते हैं। इसलिए, एक कुकी हेडर को किसी अन्य क्लाइंट में कॉपी करना पृष्ठ को पुनर्मानित करने में विफल हो सकता है, भले ही कुकी स्वयं मान्य हो। कुकी तंत्र को टूटे हुए घोषित करने से पहले सही ब्राउज़र स्थिति की सीमा पर कार्यप्रवाह को फिर से बनाएं।

निष्कर्ष

एक कुकी एक ब्राउज़र-प्रबंधित HTTP स्थिति है जिसका एक परिभाषित दायरा और जीवनकाल होता है। यह सत्रों और प्राथमिकताओं का समर्थन कर सकता है, लेकिन यह सुरक्षा और गोपनीयता की जिम्मेदारियाँ भी लाता है। इसके गुणधर्मों को सर्वर की सत्र नीति और ब्राउज़र के वास्तविक अनुरोध व्यवहार के साथ पढ़ें।

अधिकृत ब्राउज़र स्थिति प्रबंधित करें

एजेंट ब्राउज़र सत्रों का उपयोग करें जिनमें स्पष्ट खाता सीमाएँ हों और उस स्थिति का निरीक्षण करें जिसकी वास्तव में आपके कार्यप्रवाह को आवश्यकता है।

आज साइन अप करें और पाएं $5 निःशुल्क श्रेय — कोई क्रेडिट कार्ड आवश्यक नहीं है.

आपका $5 श्रेय प्राप्त करें →

प्रश्नोत्तर

क्या एक कुकी हमेशा व्यक्तिगत जानकारी रखती है?

नहीं। एक कुकी एक प्राथमिकता या एक अपारदर्शी पहचानकर्ता को संग्रहीत कर सकती है। यदि एक पहचानकर्ता एक व्यक्ति या अधिकृत सत्र से संबंधित है तो वह संवेदनशील हो सकता है। इसके उद्देश्य की व्याख्या अनुप्रयोग संदर्भ में करें न कि इसके लंबाई या रूप पर।

एक सत्र कुकी और एक स्थायी कुकी के बीच क्या अंतर है?

एक स्थायी कुकी एक स्पष्ट जीवनकाल लेकर आती है जैसे कि Max-Age या Expires। एक सत्र कुकी में वह स्थायी सेटिंग नहीं होती है, हालांकि ब्राउज़र सत्र पुनर्स्थापन यह प्रभावित कर सकता है कि यह कब गायब होती है। सर्वर-साइड सत्र की वैधता एक अलग नियम है।

क्या HttpOnly एक कुकी को भेजने से रोकता है?

नहीं। HttpOnly सामान्य पृष्ठ JavaScript को कुकी को पढ़ने से प्रतिबंधित करता है, लेकिन ब्राउज़र अभी भी इसे पात्र HTTP अनुरोधों पर भेज सकता है। सुरक्षित, SameSite, डोमेन, पथ, और समाप्ति नियम यह भी प्रभावित करते हैं कि क्या इसे भेजा जाता है।

क्या एक ब्राउज़र प्रोफ़ाइल लॉगिन स्थिति को बनाए रख सकती है?

एक ब्राउज़र प्रोफ़ाइल कुकीज़ और अन्य स्थिति को बनाए रख सकती है जब उत्पाद निरंतरता का समर्थन करता है, लेकिन एक कार्यात्मक लॉगिन भी सर्वर-साइड सत्र की वैधता पर निर्भर करता है। केवल अधिकृत खातों के लिए प्रोफ़ाइल बनाएं और उन्हें संभावित संवेदनशील क्रेडेंशियल्स के रूप में सुरक्षित रखें।

संदर्भ