जवाबों:
वर्तमान कुकी विनिर्देश RFC 6265 है , जो RFC 2109 और RFC 2965 को प्रतिस्थापित करता है (दोनों RFC को अब "ऐतिहासिक" के रूप में चिह्नित किया गया है) और कुकीज़ के वास्तविक-विश्व usages के लिए सिंटैक्स को औपचारिक रूप दिया गया है। यह स्पष्ट रूप से बताता है:
- परिचय
...
ऐतिहासिक कारणों से, कुकीज़ में कई सुरक्षा और गोपनीयता संबंधी असमानताएँ होती हैं। उदाहरण के लिए, एक सर्वर यह संकेत दे सकता है कि किसी दिए गए कुकी का इरादा "सुरक्षित" कनेक्शन के लिए है, लेकिन सुरक्षित विशेषता एक सक्रिय नेटवर्क हमलावर की उपस्थिति में अखंडता प्रदान नहीं करती है। इसी तरह, किसी दिए गए होस्ट के लिए कुकीज़ को उस होस्ट के सभी बंदरगाहों पर साझा किया जाता है, भले ही वेब ब्राउज़र द्वारा उपयोग की जाने वाली सामान्य "समान-मूल नीति" अलग-अलग बंदरगाहों के माध्यम से प्राप्त सामग्री को अलग करती है।
और भी:
8.5। कमजोर गोपनीयता
पोर्ट द्वारा कुकीज़ अलगाव प्रदान नहीं करते हैं । यदि कोई कुकी एक पोर्ट पर चल रही सेवा द्वारा पढ़ने योग्य है, तो कुकी उसी सर्वर के किसी अन्य पोर्ट पर चल रही सेवा द्वारा भी पठनीय है। यदि कोई कुकी एक पोर्ट पर किसी सेवा द्वारा लिखने योग्य है, तो कुकी उसी सर्वर के किसी अन्य पोर्ट पर चल रही सेवा द्वारा भी लिखने योग्य है। इस कारण से, सर्वर SHOULD दोनों एक ही मेजबान के विभिन्न बंदरगाहों पर पारस्परिक रूप से डिस्ट्रेस्टिंग सेवाएं नहीं चलाते हैं और संवेदनशील जानकारी संग्रहीत करने के लिए कुकीज़ का उपयोग करते हैं।
RFC2965 3.3.1 के अनुसार (जो ब्राउज़रों द्वारा अनुसरण नहीं किया जा सकता है), जब तक कि पोर्ट हेडर के portपैरामीटर के माध्यम से स्पष्ट रूप से निर्दिष्ट नहीं किया जाता है Set-Cookie, कुकीज़ को किसी भी पोर्ट पर भेजा जा सकता है या नहीं भेजा जा सकता है।
Google की ब्राउज़र सुरक्षा हैंडबुक कहती है: डिफ़ॉल्ट रूप से, कुकी का दायरा वर्तमान होस्ट नाम के सभी URL तक सीमित है - और पोर्ट या प्रोटोकॉल जानकारी के लिए बाध्य नहीं है। और कुछ पंक्तियाँ बाद में केवल एक DNS नाम के लिए कुकीज़ को सीमित करने का कोई तरीका नहीं है [...] इसी तरह, उन्हें एक विशिष्ट बंदरगाह तक सीमित करने का कोई तरीका नहीं है। (इसके अलावा, यह ध्यान रखें, कि IE इसकी एक ही मूल नीति में कारक पोर्ट संख्या करता है सब पर ।)
इसलिए यहां किसी भी परिभाषित व्यवहार पर भरोसा करना सुरक्षित नहीं लगता है।
यह वास्तव में एक पुराना सवाल है, लेकिन मुझे लगा कि मैं अपने द्वारा इस्तेमाल किया जाने वाला वर्कअराउंड जोड़ दूंगा।
मेरे पास अपने लैपटॉप पर दो सेवाएं चल रही हैं (एक पोर्ट 3000 पर और दूसरा 4000 पर)। जब मैं ( http://localhost:3000और http://localhost:4000) के बीच कूद जाता , तो क्रोम उसी कुकी में पास हो जाता, प्रत्येक सेवा कुकी को नहीं समझती और एक नया निर्माण करती।
मैंने पाया कि अगर मैंने एक्सेस किया http://localhost:3000और http://127.0.0.1:4000, समस्या दूर हो गई क्योंकि क्रोम ने लोकलहोस्ट के लिए एक कुकी और 127.0.0.1 के लिए एक रखा।
फिर, कोई भी इस बिंदु पर ध्यान नहीं दे सकता है लेकिन यह मेरी स्थिति के लिए आसान और उपयोगी था।
localhostसाथ साझा नहीं किया जा सकता 127.0.0.1और इसके विपरीत एक कुकी । लेकिन एक ही मेजबान / डोमेन पर कुकीज़, बंदरगाह की परवाह किए बिना, पहनने योग्य हैं।
यह कुकी SOP (समान उत्पत्ति नीति) में एक बड़ा ग्रे क्षेत्र है।
सैद्धांतिक रूप से, आप डोमेन में पोर्ट नंबर निर्दिष्ट कर सकते हैं और कुकी साझा नहीं की जाएगी। व्यवहार में, यह कई ब्राउज़रों के साथ काम नहीं करता है और आप अन्य मुद्दों में भाग लेंगे। इसलिए यह केवल तभी संभव है जब आपकी साइटें आम जनता के लिए न हों और आप नियंत्रित कर सकें कि किन ब्राउज़रों का उपयोग करना है।
बेहतर तरीका यह है कि एक ही आईपी के लिए 2 डोमेन नाम प्राप्त करें और कुकीज़ के लिए पोर्ट नंबर पर निर्भर न रहें।
समस्या के चारों ओर जाने का एक वैकल्पिक तरीका है, सत्र कुकी का नाम पोर्ट संबंधी हो। उदाहरण के लिए:
आपका कोड यह पता लगाने के लिए वेबसर्वर कॉन्फ़िगरेशन का उपयोग कर सकता है कि आपका सर्वर किस पोर्ट का उपयोग करता है, और तदनुसार कुकी का नाम दें।
ध्यान रखें कि आपके आवेदन को दोनों कुकीज़ प्राप्त होंगी, और आपको अपने पोर्ट से मेल खाने वाले से अनुरोध करने की आवश्यकता है।
कुकी नाम में सटीक पोर्ट संख्या होने की आवश्यकता नहीं है, लेकिन यह अधिक सुविधाजनक है।
सामान्य तौर पर, कुकी नाम आपके द्वारा उपयोग किए जाने वाले सर्वर उदाहरण के लिए विशिष्ट किसी अन्य पैरामीटर को एन्कोड कर सकता है, इसलिए इसे सही संदर्भ द्वारा डिकोड किया जा सकता है।
मैं एक समान समस्या का सामना कर रहा था (और डिबग करने की कोशिश कर रहा था) एक ही मशीन पर दो अलग-अलग Django एप्लिकेशन।
मैं उन्हें इन आदेशों के साथ चला रहा था:
./manage.py runserver 8000
./manage.py runserver 8001
जब मैंने पहले एक में लॉगिन किया था और फिर दूसरे एक में मैंने हमेशा पहले वाले और उपाध्यक्ष को लॉग आउट किया था।
मैंने इसे अपने / आदि / मेजबानों पर जोड़ा
127.0.0.1 app1
127.0.0.1 app2
फिर मैंने इन कमांड के साथ दो ऐप शुरू किए:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
समस्या सुलझ गयी :)
127.0.0.1:8000हैं, एक के लिए localhost:8000एक पल के लिए, और संभवतः ::1:8000(शायद [::1]:8080कभी मेजबान फ़ाइल स्पर्श किए बिना) एक तिहाई के लिए।
::1 app1 app2 app3 app4 app5 appN
यह वैकल्पिक है।
पोर्ट निर्दिष्ट किया जा सकता है इसलिए कुकीज़ विशिष्ट पोर्ट हो सकते हैं। यह आवश्यक नहीं है, वेब सर्वर / एप्लिकेशन को इसका ध्यान रखना चाहिए।
स्रोत: जर्मन विकिपीडिया लेख , RFC2109 , अध्याय 4.3.1
Portकरता है,Set-Cookieहेडर में पैरामीटर को समाप्त कर देता है (क्योंकि लगभग किसी ने वास्तव में इसका उपयोग नहीं किया है), और यह बहुत स्पष्ट करता है कि एक ही मेजबान पर कुकीज़ अब बंदरगाहों द्वारा दूर नहीं हैं।