ब्राउज़र कुकी डोमेन कैसे काम करते हैं?

Question

अजीब डोमेन / उपडोमेन कुकी मुद्दों के कारण जो मुझे मिल रहा है, मैं जानना चाहता हूं कि ब्राउज़र कुकीज़ कैसे संभालते हैं। यदि वे इसे अलग-अलग तरीकों से करते हैं, तो मतभेदों को जानना भी अच्छा होगा।

दूसरे शब्दों में - जब कोई ब्राउज़र कुकी प्राप्त करता है, तो उस कुकी MAY में एक डोमेन और उससे जुड़ा एक पथ होता है। या नहीं, जिस स्थिति में ब्राउज़र शायद उनके लिए कुछ डिफॉल्ट करता है। प्रश्न 1: वे क्या हैं?

बाद में, जब ब्राउज़र अनुरोध करने वाला होता है, तो वह अपने कुकीज़ की जांच करता है और उन लोगों को फ़िल्टर करता है जिन्हें उसे उस अनुरोध के लिए भेजना चाहिए। यह अनुरोध पथ और डोमेन के विरुद्ध मिलान करके ऐसा करता है। प्रश्न 2: मिलान नियम क्या हैं?

---

जोड़ा गया:

कारण मैं यह पूछ रहा हूँ क्योंकि मैं कुछ किनारे के मामलों में रुचि रखता हूं। पसंद:

• के लिए एक कुकी .example.comउपलब्ध होगी www.example.com?
• के लिए एक कुकी .example.comउपलब्ध होगी example.com?
• के लिए एक कुकी example.comउपलब्ध होगी www.example.com?
• के लिए एक कुकी example.comउपलब्ध होगी anotherexample.com?
• के www.example.comलिए कुकी सेट करने में सक्षम होगा example.com?
• के www.example.comलिए कुकी सेट करने में सक्षम होगा www2.example.com?
• के www.example.comलिए कुकी सेट करने में सक्षम होगा .com?
• आदि।

जोड़ा गया 2:

इसके अलावा, क्या कोई सुझाव दे सकता है कि मुझे एक कुकी कैसे सेट करनी चाहिए ताकि:

• इसे www.example.comया तो सेट किया जा सकता है या example.com;
• यह दोनों www.example.comऔर के द्वारा सुलभ है example.com।

Answer 1

हालाँकि RFC 2965 है ( Set-Cookie2,, पहले से ही RFC 2109 का पालन कर चुका था ) जो आजकल कुकी को परिभाषित करता है, अधिकांश ब्राउज़र पूरी तरह से समर्थन नहीं करते हैं लेकिन नेटस्केप द्वारा मूल विनिर्देश का पालन करते हैं ।

डोमेन विशेषता मान और प्रभावी डोमेन के बीच एक अंतर है : पूर्व को Set-Cookieहेडर फ़ील्ड से लिया गया है और बाद में उस विशेषता मान की व्याख्या है। RFC 2965 के अनुसार, निम्नलिखित आवेदन करना चाहिए:

• यदि सेट-कुकी हेडर फ़ील्ड में डोमेन विशेषता नहीं है , तो प्रभावी डोमेन अनुरोध का डोमेन है।
• यदि कोई डोमेन विशेषता मौजूद है, तो इसका मान प्रभावी डोमेन के रूप में उपयोग किया जाएगा (यदि मान .क्लाइंट से शुरू नहीं किया जाएगा)।

प्रभावी डोमेन होने पर इसे सेट होने के लिए वर्तमान अनुरोधित डोमेन से भी मेल खाना चाहिए ; अन्यथा कुकी को संशोधित किया जाएगा। अनुरोध में भेजे जाने वाले कुकीज़ को चुनने के लिए भी यही नियम लागू होता है।

---

इस ज्ञान को अपने प्रश्नों पर मैप करते हुए, निम्नलिखित को लागू करना चाहिए:

• के साथ कुकी www.example.com के लिए उपलब्ध Domain=.example.com होगी
• कुकी के साथ example.com के लिए उपलब्ध Domain=.example.com होगा
• कुकी के साथ Domain=example.comपरिवर्तित किया जाएगा.example.com और इस प्रकार www.example.com के लिए भी उपलब्ध होगा
• के साथ कुकी anotherexample.com के लिए उपलब्ध नहींDomain=example.com होगी
• www.example.com example.com के लिए कुकी सेट करने में सक्षम होगा
• www.example.com होगा नहीं के लिए सेट कुकी के लिए सक्षम हो www2.example.com
• www.example.com होगा नहीं के लिए सेट कुकी के लिए सक्षम हो .com

और www.example.com द्वारा / के लिए कुकी सेट और पढ़ना और example.com के , क्रमशः .www.example.comऔर इसके लिए सेट करें .example.com। लेकिन पहला ( .www.example.com) केवल उस डोमेन के नीचे के अन्य डोमेन (उदाहरण के लिए foo.www.example.com या bar.www.example.com ) .example.comतक पहुँचा जा सकता है, जहाँ example.com (उदाहरण foo) के नीचे किसी अन्य डोमेन द्वारा भी पहुँचा जा सकता है । example.com या bar.example.com )।

Comments

@Gumbo तो abcexample.com डोमेन c.example.com के साथ कुकी तक पहुँच सकता है?

— पचेरियर

बहुत देर से इस सवाल का पालन करें। मेरा अपना अनुभव और यह: webmasters.stackexchange.com/questions/55790/… सुझाव है कि example.com का डोमेन www.example.com के लिए उपलब्ध नहीं होगा, लेकिन यह उदाहरण अन्यथा सुझाव देता है। क्या यह उदाहरण गलत है, या मैं (काफी संभव) गलतफहमी हूं। थ्रेड नेक्रोमेंसी के लिए क्षमा करें, लेकिन यह सुनिश्चित करना चाहता था कि यह उत्कृष्ट उत्तर मेरे जैसे भविष्य के भ्रमित होने वाले

— न्यूबाइट्स के

यह उत्तर थोड़ा पुराना है; देख मेरा उत्तर नीचे।

— झोंगयू

example.com के लिए सेटिंग www.example.com के लिए उपलब्ध क्यों नहीं है? (जैसा कि example.com का "www" उप है;

— नबील खान

सेट-कुकी 2 अपने आप में अप्रचलित है। सेट-कुकी का उपयोग जारी रखें।

— जोफोरकर

Answer 2

पिछले जवाब थोड़े पुराने हैं।

उस समय ब्राउज़र सर्वसम्मति के आधार पर, RFC 6265 2011 में प्रकाशित हुआ था। तब से, सार्वजनिक प्रत्यय डोमेन के साथ कुछ जटिलताएं हैं। मैंने वर्तमान स्थिति को स्पष्ट करते हुए एक लेख लिखा है - http://bayou.io/draft/cookie.domain.html

संक्षेप में, कुकी डोमेन के बारे में पालन करने के लिए नियम:

• मूल डोमेन एक कुकी के उद्भव अनुरोध का डोमेन है।

• यदि मूल डोमेन एक IP है, तो कुकी का डोमेन विशेषता सेट नहीं होना चाहिए।

• यदि कुकी का डोमेन विशेषता सेट नहीं है, तो कुकी केवल उसके मूल डोमेन पर लागू होती है।

• यदि कुकी का डोमेन विशेषता सेट है,

  • कुकी उस डोमेन और उसके सभी उप-डोमेन पर लागू होती है;
  • कुकी का डोमेन मूल डोमेन के समान या माता-पिता का होना चाहिए
  • कुकी का डोमेन TLD, सार्वजनिक प्रत्यय या सार्वजनिक प्रत्यय का जनक नहीं होना चाहिए।

यह कहा जा सकता है कि एक कुकी हमेशा अपने मूल डोमेन पर लागू होती है।

कुकी डोमेन में एक प्रमुख डॉट नहीं होना चाहिए, जैसे कि .foo.com- बस उपयोग करेंfoo.com

उदहारण के लिए,

• x.y.z.comस्वयं या माता-पिता के लिए एक कुकी डोमेन सेट कर सकते हैं - x.y.z.com, y.z.com, z.com। लेकिन नहीं com, जो एक सार्वजनिक प्रत्यय है।
• डोमेन के साथ कुकी = y.z.comके लिए लागू है y.z.com, x.y.z.com, a.x.y.z.comआदि

सार्वजनिक प्रत्यय के उदाहरण - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Comments

@roelleor - यह दूसरा तरीका है। rfc6265 को संक्षेप में लिखा गया था कि वास्तव में कुकीज़ को कैसे संभाला गया था :) हाँ, rfc एक सटीक सटीक प्रतिबिंब है कि प्रमुख ब्राउज़र कैसे व्यवहार करते हैं। ब्राउज़रों पर मेरे हालिया परीक्षणों ने पुष्टि की है कि। हालांकि, वे सार्वजनिक प्रत्ययों से जुड़े कोने के मामलों में भिन्न हो सकते हैं।

— झोंगयु जू

एक अग्रणी बिंदु के परिणाम क्या हैं?

— 11 अक्टूबर को TheTheCreek

@UpTheCreek - rfc6265 के अनुसार, अग्रणी डॉट को क्लाइंट द्वारा नजरअंदाज किया जाना चाहिए

— ZhongYu

क्या यह अजीब नहीं है कि x.y.z.comकुकी को सेट किया जा सकता है z.com?

— रॉय नमिर

तो अगर xyzcom yzcom के लिए कुकी सेट कर सकता है, और डोमेन yzcom के साथ कुकी wyzcom पर लागू होता है ... क्या इसका मतलब यह है कि xyzcom wyzcom के लिए कुकी सेट कर सकता है ?

— आयोना

Answer 3

एक व्यापक कवरेज समीक्षा के लिए RFC2965 की सामग्री । निश्चित रूप से इसका मतलब यह नहीं है कि सभी ब्राउज़र बिल्कुल उसी तरह व्यवहार करते हैं।

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

डोमेन के लिए मिलान नियमों को कुकी डोमेन को होस्ट से मिलान करने की आवश्यकता होती है, जिसके लिए अनुरोध किया जा रहा है। कुकी में * शामिल करके एक व्यापक डोमेन मिलान निर्दिष्ट किया जा सकता है। सेट-कुकी के डोमेन विशेषता में (यह एक क्षेत्र जो ब्राउज़र भिन्न हो सकते हैं)। पथ से मिलान करना (डोमेन के मैचों को मानना) एक साधारण बात है कि अनुरोधित पथ कुकी पर निर्दिष्ट पथ के अंदर होना चाहिए। आमतौर पर सत्र कुकीज़ पथ = / या पथ = / applicationName के साथ सेट की जाती हैं / इसलिए कुकी आवेदन में सभी अनुरोधों के लिए उपलब्ध है।

---

जोड़ा गया प्रतिक्रिया:

• क्या www.example.com के लिए .example.com एक कुकी उपलब्ध होगी? हाँ
• क्या example.com के लिए .example.com एक कुकी उपलब्ध होगी? पता नहीं
• क्या example.com के लिए एक कुकी www.example.com के लिए उपलब्ध होगी? नहीं करना चाहिए लेकिन ... *
• क्या example.com के लिए कुकी anotherexample.com के लिए उपलब्ध होगी? नहीं
• क्या www.example.com example.com के लिए कुकी सेट कर पाएगा? हाँ
• क्या www.example.com www2.example.com के लिए कुकी सेट कर पाएगा? नहीं (को छोड़कर .example.com)
• क्या www.example.com .com के लिए कुकी सेट कर पाएगा? नहीं (इस कुकी को नाम स्थान से ऊपर सेट नहीं किया जा सकता है और न ही आप .co.uk जैसी किसी चीज़ के लिए सेट कर सकते हैं)। ।

*मैं अभी इसका परीक्षण करने में असमर्थ हूं, लेकिन मेरे पास एक संकेत है कि कम से कम IE7 / 6 पथ का इलाज करेगा example.comजैसे कि यह था .example.com।

Comments

मैंने अपने प्रश्न में कुछ दिलचस्प बढ़त मामले जोड़े हैं। क्या आप उस पर कुछ सराह सकते हैं?

— विल्क्स-

Answer 4

इस मुद्दे के लिए अंतिम (तीसरा बिल्कुल) RFC RFC-6265 (Obsoletes RFC-2965 है जो बदले में RFC-2109 है)।

इसके अनुसार यदि सर्वर डोमेन विशेषता को छोड़ देता है, तो उपयोगकर्ता एजेंट केवल मूल सर्वर (जिस सर्वर पर दिया गया संसाधन रहता है) कुकी वापस कर देगा । लेकिन यह भी चेतावनी है कि कुछ मौजूदा उपयोगकर्ता एजेंट अनुपस्थित डोमेन विशेषता का इलाज करते हैं जैसे कि डोमेन विशेषता मौजूद थी और इसमें वर्तमान होस्ट नाम शामिल था (उदाहरण के लिए, यदि example.com एक डोमेन-विशेषता के बिना सेट-कुकी शीर्ष लेख लौटाता है ये उपयोगकर्ता एजेंट करेंगे गलती से कुकी को www.example.com पर भी भेजें)।

जब डोमेन विशेषता निर्दिष्ट की गई है, तो इसे पूर्ण डोमेन नाम के रूप में माना जाएगा (यदि विशेषता में अग्रणी डॉट है तो इसे अनदेखा किया जाएगा)। सर्वर को इस कुकी को प्राप्त करने के लिए विशेषता में निर्दिष्ट डोमेन से मेल खाना चाहिए (ठीक उसी डोमेन नाम या इसका उपडोमेन होना चाहिए)। अधिक सटीक रूप से यह यहाँ निर्दिष्ट है ।

इसलिए, उदाहरण के लिए:

• कुकी विशेषता Domain=.example.comके बराबर हैDomain=example.com
• इस तरह के डोमेन विशेषताओं वाले कुकीज़ example.com और www.example.com के लिए उपलब्ध होंगे
• ऐसी डोमेन विशेषताओं वाली कुकीज़ अन्य के लिए उपलब्ध नहीं होंगी-example.com
• कुकी विशेषता निर्दिष्ट Domain=www.example.comकरने से www4.example.com का रास्ता बंद हो जाएगा

पुनश्च: डोमेन विशेषता में अल्पविराम अनुगामी उपयोगकर्ता एजेंट के कारण विशेषता को अनदेखा करेगा = (

Answer 5

मैंने 2019 में नवीनतम क्रोम, फ़ायरफ़ॉक्स, सफारी में सभी मामलों का परीक्षण किया।

जोड़ा गया प्रतिक्रिया:

• क्या www.example.com के लिए .example.com एक कुकी उपलब्ध होगी? हाँ
• क्या example.com के लिए .example.com एक कुकी उपलब्ध होगी? हाँ
• क्या example.com के लिए एक कुकी www.example.com के लिए उपलब्ध होगी? नहीं , वाइल्डकार्ड के बिना डोमेन केवल खुद से मेल खाता है।
• क्या example.com के लिए कुकी anotherexample.com के लिए उपलब्ध होगी? नहीं
• क्या www.example.com example.com के लिए कुकी सेट कर पाएगा? नहीं , यह '.example.com' के लिए कुकी सेट करने में सक्षम होगा, लेकिन 'example.com' पर नहीं।
• क्या www.example.com www2.example.com के लिए कुकी सेट कर पाएगा? सं । लेकिन यह .example.com के लिए कुकी सेट कर सकता है, जिसे www2.example.com एक्सेस कर सकता है।
• क्या www.example.com .com के लिए कुकी सेट करने में सक्षम होगा? नहीं

Answer 6

RFC को वास्तविकता को प्रतिबिंबित नहीं करने के लिए जाना जाता है।

बेहतर चेक ड्राफ्ट- ietf-httpstate-कुकी , कार्य प्रगति पर है।

Answer 7

ऐसे नियम हैं जो निर्धारित करते हैं कि क्या ब्राउज़र सेट-हेडर प्रतिक्रिया हेडर (सर्वर-साइड कुकी लेखन) को स्वीकार करेगा, जावास्क्रिप्ट के उपयोग से कुकी सेट के लिए थोड़ा अलग नियम / व्याख्याएं (मैंने VBScript का परीक्षण नहीं किया है)।

फिर ऐसे नियम हैं जो यह निर्धारित करते हैं कि ब्राउज़र पेज अनुरोध के साथ एक कुकी भेजेगा या नहीं।

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

Answer 8

कुकीज़ को अस्वीकार करने के बारे में मैं 3.3.2 पढ़कर हैरान था:

http://tools.ietf.org/html/rfc2965

वह कहता है कि एक ब्राउज़र को डोमेन .z.com के साथ xyzcom से एक कुकी को अस्वीकार करना चाहिए, क्योंकि 'xy' में एक डॉट होता है। इसलिए, जब तक कि मैं RFC और / या ऊपर दिए गए प्रश्नों के बारे में गलत जानकारी नहीं दे रहा हूं, तब तक कुछ प्रश्न जोड़े जा सकते हैं:

क्या www.yyy.example.com के लिए .example.com एक कुकी उपलब्ध होगी? नहीं।

क्या डोमेन .example.com के साथ मूल सर्वर www.yyy.example.com द्वारा एक कुकी सेट की जाती है, क्या यह उपयोगकर्ता एजेंट द्वारा xxx.example.com को भेजी गई है? नहीं।

Comments

वह आरएफसी पुराना है। नई आरएफसी 6265, ब्राउज़र आम सहमति पर आधारित, साथ कुकी की अनुमति देता है z.comके लिए लागू किया जा करने के लिए z.comऔर सभी उप डोमेन।

— झोंगयू

Answer 9

के www.example.comलिए कुकी सेट करने में सक्षम होगा .com?

नहीं, लेकिन के example.com.frलिए एक कुकी सेट करने में सक्षम हो सकता है example2.com.fr। फ़ायरफ़ॉक्स TLDs की एक सूची को बनाए रखते हुए इससे बचाता है: http://securitylabs.websense.com/content/Blogs/3108.aspx

जाहिरा तौर पर इंटरनेट एक्सप्लोरर दो-अक्षर डोमेन को कुकीज़ सेट करने की अनुमति नहीं देता है, जो मुझे लगता है कि बताते हैं कि क्यों o2.ieबस को पुनर्निर्देशित किया जाता है o2online.ie। मैं अक्सर सोचता था कि

Comments

"com.fr" को "सार्वजनिक प्रत्यय" के रूप में माना जाता है। कुकी डोमेन सार्वजनिक प्रत्यय नहीं हो सकता। देखें rfc 6265 और publicsuffix.org

— ZhongYu

हाँ, एक समाधान है, लेकिन यह एक बहुत ही गन्दा है। इस तरह के लेबलिंग को DNS में बेक किया जाना चाहिए, अलग-अलग तदर्थ आधार पर नहीं।

— TRIG

सच है, और हो सकता है कि आप "डब" का जिक्र कर रहे हों। लेकिन यह अधिक समस्याएं पैदा कर सकता है; जैसे, http क्लाइंट कार्यान्वयन के लिए एक चुनौती प्रस्तुत करना।

— झोंगयू

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

— ६:२६ पर डी.वी.आईप्सन