मुझे पता है कि secure ध्वज वाला कुकी एक अनएन्क्रिप्टेड कनेक्शन के माध्यम से नहीं भेजी जाएगी। मुझे आश्चर्य है कि यह गहराई से कैसे काम करता है।कुकी "सुरक्षित" ध्वज कैसे काम करता है?
यह निर्धारित करने के लिए कौन जिम्मेदार है कि कुकी भेजी जाएगी या नहीं? एन्क्रिप्टेड कनेक्शन के लिए और इस यह केवल
ग्राहक सेट RFC 6265 में परिभाषित किया गया है:
सुरक्षित विशेषता कुकी के लिए चैनलों "सुरक्षित" के दायरे को सीमित करता है (जहां "सुरक्षित" उपयोगकर्ता एजेंट द्वारा परिभाषित किया गया है)। जब कुकी में सुरक्षित विशेषता होती है, तो उपयोगकर्ता एजेंट केवल HTTP अनुरोध में कुकी को शामिल करेगा यदि अनुरोध एक सुरक्षित चैनल पर प्रसारित किया जाता है (आमतौर पर ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) पर HTTP HTTP [आरएफसी 2818])।
हालांकि सक्रिय नेटवर्क हमलावरों से कुकीज़ की सुरक्षा के लिए प्रतीत होता है, सुरक्षित विशेषता केवल कुकी की गोपनीयता की रक्षा करती है। एक सक्रिय नेटवर्क हमलावर एक असुरक्षित चैनल से सुरक्षित कुकीज़ को ओवरराइट कर सकता है, उनकी अखंडता को बाधित कर सकता है (अधिक जानकारी के लिए धारा 8.6 देखें)।
बस इस विषय पर एक और शब्द:
छोड़ना secure क्योंकि अपनी वेबसाइट example.com पूरी तरह से https है पर्याप्त नहीं है।
यदि आपका उपयोगकर्ता स्पष्ट रूप से http://example.com पर पहुंच रहा है, तो उसे https://example.com पर रीडायरेक्ट किया जाएगा लेकिन यह बहुत देर हो चुका है, पहले अनुरोध में कुकी शामिल थी।
मुझे पता है कि यह पुराना है, लेकिन एचएसटीएस प्रीलोड इस समस्या को अक्सर होने से रोकने में मदद करता है। यह अभी भी 100% तय नहीं है, लेकिन अगर आप वास्तव में सुरक्षित कुकी से बचना चाहते हैं तो यह एक और बात है। –
@ श्रीमोनो क्रोम आप सुरक्षित कुकी से क्यों बचना चाहते हैं? – MEMark
@ श्रीमोनो क्रोम हालांकि कुछ पुराने या निचले स्पेस ब्राउज़र, मुझे विश्वास है, एचएसटीएस – Anthony
यदि क्लाइंट-साइड में अभी तक कुकी नहीं है और उन्हें सर्वर-साइड (उदा। लॉगिंग इन) से भेजा जाना चाहिए, तो सर्वर में पक्ष को प्रतिक्रिया में शामिल करने का निर्णय लेने वाला एक होगा? – ted
सर्वर प्रारंभ में "सेट-कुकी हेडर" के माध्यम से कुकीज़ सेट करता है – Ivan