क्या subdomain.example.com एक कुकी सेट कर सकता है जिसे example.com द्वारा पढ़ा जा सकता है?

Question

मैं बस विश्वास नहीं कर सकता यह निर्धारित करने के लिए बहुत कठिन है।

RFC को पढ़ने के बाद भी, यह मेरे लिए स्पष्ट नहीं है कि क्या subdomain.example.com पर एक सर्वर एक कुकी सेट कर सकता है जिसे example.com द्वारा पढ़ा जा सकता है।

subdomain.example.com एक कुकी सेट कर सकता है जिसका डोमेन विशेषता .example.com है। RFC 2965 में स्पष्ट रूप से कहा गया है कि इस तरह के कुकी को example.com पर नहीं भेजा जाएगा, लेकिन फिर समान रूप से यह कहता है कि यदि आप डोमेन = example.com सेट करते हैं, तो एक डॉट प्रीपेड है, जैसे कि आपने .example.com कहा है। एक साथ लिया गया है, ऐसा लगता है कि अगर example.com रिटर्न डोमेन = example.com के साथ एक कुकी सेट करता है, तो उसे वह कुकी वापस नहीं मिलती है! यह सही नहीं हो सकता।

क्या कोई स्पष्ट कर सकता है कि नियम वास्तव में क्या हैं?

Comments

जब यह पूछा गया तो यह सवाल बंद / माइग्रेट किया जाना चाहिए था, लेकिन चूंकि इसने बहुत ध्यान दिया, इसलिए मैं इसे बंद करने के बजाय इसे बंद करने जा रहा हूं। सही साइट पर stackoverflow.com/questions/3089199/ के लिए देखें ।

— क्रिस एस

Answer 1

आपके द्वारा पढ़े गए उसी RFC2109 से उद्धरण :

       * डोमेन = .foo.com के लिए अनुरोध-होस्ट x.foo.com से एक सेट-कुकी
         स्वीकृत होना।

तो के subdomain.example.comलिए एक कुकी सेट कर सकते हैं .example.com। अब तक सब ठीक है।

       निम्नलिखित नियम लागू कुकी-मानों को चुनने के लिए लागू होते हैं
       उन सभी कुकीज़ के बीच जो यूजर एजेंट के पास है।

       डोमेन चयन
            मूल सर्वर का पूर्ण-योग्य होस्ट नाम डोमेन-मिलान होना चाहिए
            कुकी की डोमेन विशेषता

तो क्या हमारे पास एक डोमेन-मैच है?

   * एक एफक्यूडीएन स्ट्रिंग है और इसमें एनबी है, जहां एन एक गैर-खाली नाम है
     string, B का form है .B ', और B' एक FQDN स्ट्रिंग है। (तो, xycom
     डोमेन-मैच .y.com लेकिन y.com नहीं।)

लेकिन अब परिभाषा के अनुसार example.comडोमेन-मैच नहीं होगा .example.com। लेकिन www.example.com(या डोमेन में कोई अन्य "गैर-खाली नाम") होगा। यह RFC , RFC2965 द्वारा प्रचलित सिद्धांत के अनुसार है , जिसने Set-Cookie2परिचालन पर डोमेन के लिए एक अग्रणी डॉट बनाने के बारे में बातें तय कीं ।

अधिक महत्वपूर्ण, जैसा कि @Tony द्वारा उल्लेख किया गया है, वास्तविक दुनिया है। वास्तविक उपयोगकर्ता एजेंट क्या कर रहे हैं, इसकी एक झलक के लिए देखें

फ़ायरफ़ॉक्स 3 के nsCookieService.cpp

तथा

Chrome की कुकी_monster.cc

वास्तविक साइटों क्या कर रहे हैं में परिप्रेक्ष्य के लिए, के साथ खेल की कोशिश wgetका उपयोग कर --save-cookies, --load-cookiesऔर --debugदेखने के लिए क्या हो रहा है।

आपको पता चलेगा कि वास्तव में अधिकांश साइटें Set-Cookie"होस्ट" मानों के साथ पुराने RFC स्पेक से कुछ संयोजन का उपयोग कर रही हैं , जो कि बिना किसी प्रमुख डॉट (जैसे कि twitter.com करता है) या डोमेन वैल्यू (एक प्रमुख बिंदी के साथ) और पुनर्निर्देशन के बिना है। सर्वर की तरह www.example.com(जैसे google.com करता है)।

Comments

तो कैसे www.example.com और example.com (जो आमतौर पर एक ही साइट की ओर इशारा करते हैं) एक ही कुकीज़ का उपयोग करते हैं? सबसे आगे वाला । अधिकांश ब्राउज़रों में आवश्यक नहीं हो सकता है अन्यथा यह सामान्य उपयोग काम नहीं करेगा।

— जेम्सरैन

लीडिंग डॉट केवल RFC द्वारा हाल ही में मजबूर किया गया है। example.com "example.com" और ".example.com" के लिए कुकीज़ सेट कर सकता है; बाद में www.example.com द्वारा पढ़ा जा सकता है। जो हो रहा है उसे देखने के लिए दिखाए गए wget कमांड का उपयोग करें।

— मदीना

@medina, क्या कोई उपयोगकर्ता X1.yz पर कुकीज़ सेट कर सकता है और इसे x2.yz पर पढ़ सकता है ?

— पैकरियर

@Pacerier सिर्फ अगर (1) आप के लिए कुकी सेट y.zऔर (2) उपयोगकर्ता-एजेंट लागू आरएफसी 6265

— माइकल हैम्पटन

@Michael Hampton, ब्राउज़र्स RFC 6265 को लागू नहीं करते हैं?

— पेसियर

Answer 2

यदि ब्राउज़र RFC 6265 को लागू करता है , जो किसी भी आधुनिक ब्राउज़र को इस बिंदु पर करना चाहिए, तो एक कुकी सेट के लिए .example.comअग्रणी डॉट को अनदेखा किया जाएगा (खंड 5.2.3), और कुकी को फिर नग्न डोमेन और सभी को भेजा जाएगा उप डोमेन।

यदि आपके पास पुराने ब्राउज़र से महत्वपूर्ण ट्रैफ़िक है, तो इस व्यवहार पर भरोसा न करें; यह RFC केवल 2011 तक है।

Answer 3

यह संभव नहीं होना चाहिए। हालाँकि, जैसा कि आपने कहा, चूंकि यह एक व्यापक रूप से प्रलेखित मानक नहीं है, यह इस बात पर निर्भर करता है कि आप किस सॉफ्टवेयर का उपयोग कर रहे हैं।

अधिकांश आधुनिक ब्राउज़र एक परिभाषित "वेब सुरक्षा मॉडल" का पालन करते हैं। मॉडल कुकीज़ के बारे में सुरक्षा के संबंध में ब्राउज़रों के व्यवहार को प्रभावी ढंग से नियंत्रित करता है (विशेषकर उन्हें किसी भी वेबसाइट पर वापस कैसे भेजा जाएगा)। मॉडल में यह भी नियम है कि "ब्राउज़र उन डोमेन नामों को कुकीज़ नहीं भेजते हैं जिन्होंने उन्हें सेट नहीं किया था।"

कहा जा रहा है कि, domain.com js.domain.com के लिए कुकीज़ सेट करने में सक्षम होना चाहिए। js.domain.com, हालांकि, केवल खुद के लिए कुकीज़ सेट कर सकता है। लेकिन यह सब आपके द्वारा उपयोग किए जा रहे ब्राउज़र पर निर्भर करता है।