स्पष्ट डोमेन के साथ लोकलहोस्ट पर कुकीज़


191

मुझे कुकीज़ के बारे में कुछ बुनियादी बात याद आ रही होगी। लोकलहोस्ट पर, जब मैं सर्वर साइड पर कुकी सेट करता हूं और डोमेन को स्थानीय रूप से (या .localhost) के रूप में स्पष्ट रूप से निर्दिष्ट करता हूं। कुकी को कुछ ब्राउज़रों द्वारा स्वीकार नहीं किया जाता है।

फ़ायरफ़ॉक्स 3.5: मैंने फ़ायरबग में HTTP अनुरोध की जाँच की। मैं जो देख रहा हूं वह है:

Set-Cookie:
    name=value;
    domain=localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

या (जब मैंने डोमेन .localhost पर सेट किया है):

Set-Cookie:
    name=value;
    domain=.localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

या तो मामले में, कुकी संग्रहीत नहीं है।

IE8: मैंने किसी भी अतिरिक्त टूल का उपयोग नहीं किया, लेकिन कुकी के रूप में अच्छी तरह से संग्रहीत नहीं किया जाता है, क्योंकि इसे बाद के अनुरोधों में वापस नहीं भेजा जा रहा है।

ओपेरा 9.64: लोकलहोस्ट और लोकोलॉस्ट दोनों काम करते हैं , लेकिन जब मैं वरीयता में कुकीज़ की सूची की जांच करता हूं, तो डोमेन लोकलहोस्ट के लिए सेट हो जाता है। भले ही यह लोकलहोस्ट (सूची समूह में) के तहत सूचीबद्ध हो।

सफ़ारी ४: लोकलहोस्ट और .localhost दोनों काम करते हैं , लेकिन उन्हें हमेशा प्राथमिकता में .localhost के रूप में सूचीबद्ध किया जाता है। दूसरी ओर, एक स्पष्ट डोमेन के बिना एक कुकी, इसे केवल स्थानीयहोस्ट (नो डॉट) के रूप में दिखाया जा रहा है।

लोकलहोस्ट को क्या समस्या है? इस तरह की कई विसंगतियों के कारण, लोकलहोस्ट से जुड़े कुछ विशेष नियम होने चाहिए। इसके अलावा, यह मेरे लिए पूरी तरह से स्पष्ट नहीं है कि डोमेन को एक डॉट द्वारा उपसर्ग क्यों करना चाहिए? RFC 2109 में स्पष्ट रूप से कहा गया है कि:

डोमेन विशेषता के लिए मान में कोई एम्बेडेड डॉट्स नहीं है या डॉट के साथ शुरू नहीं होता है।

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


13
6 साल पुराना धागा और यह अभी भी एक समस्या है। मैं क्रोम v40 का उपयोग कर रहा हूं। देखें यहाँ
गौई

5
Chrome 43 ... अभी भी एक बग है।
इवान कैरोल

4
क्रोम 54 यहाँ, हल नहीं
वाहिद अमीरी

6
Chrome 73 .. अभी भी उसी मुद्दे का सामना कर रहा है। :(
कोड_क्रैश

2
इसे कोई भी हल कर सकता है? अभी भी उसी s का सामना करना पड़ रहा है *** .. इस SO उत्तर को देखें
Bonjour123

जवाबों:


235

डिज़ाइन के अनुसार, डोमेन नाम में कम से कम दो बिंदु होने चाहिए; अन्यथा ब्राउज़र उन्हें अमान्य मान लेगा। ( Http://curl.haxx.se/rfc/cookie_spec.html पर संदर्भ देखें )

काम करते समय localhost, कुकी डोमेन को पूरी तरह से छोड़ दिया जाना चाहिए। बस इसे स्थापित करने के लिए ""या NULLया FALSEके बजाय "localhost"पर्याप्त नहीं है।

PHP के लिए, टिप्पणियों को देखें http://php.net/manual/en/function.setcookie.php#73107

जावा सर्वलेट एपीआई के साथ काम करते हैं, तो कॉल नहीं करते cookie.setDomain("...")सब पर विधि।


93
यह निश्चित नहीं है कि हर कोई + 1'ing क्यों है, मैंने कुकी के डोमेन को अशक्त या गलत या खाली स्ट्रिंग पर सेट किया है और यह अभी भी नहीं बचा है अगर लोकलहोस्ट पर।
जस्टिन

5
मैं RFC6265 में डोमेन में दो बिंदुओं के बारे में कहीं भी नहीं देखता: tools.ietf.org/html/rfc6265#section-5.2.3 .Net का कहना है कि इसे अपने स्थानीय डोमेन में सभी होस्ट के लिए ".local" पर सेट करें। जो ओपेरा / सफ़ारी msdn.microsoft.com/en-us/library/ckch3yd2.aspx के
MandoMando

9
@ जस्टिन: एचएम, आपको शायद Domain=कुकी सेट करते समय पैरामीटर को पूरी तरह से छोड़ना होगा । यदि आप डोमेन को केवल रिक्त या रिक्त करने के लिए सेट करते हैं, तो शायद आपका फ्रेम Domain=पैरामीटर उस मूल्य के साथ भेज देगा , बजाय इसे छोड़ने के? उदाहरण के लिए Firebug के साथ जाँच करें।
sleske

2
@ राल्फ, एक लाख धन्यवाद, इस बात ने मुझे कुछ घंटों के लिए पागल कर दिया। उम्मीद है कि डोमेन को अशक्त करने के लिए (मैं एक नेट सर्वर ढेर में हूं) एक आकर्षण की तरह काम करता है।
Xose Lluis

4
यह कुछ हद तक खराब है। "शून्य या किसी असत्य या रिक्त स्ट्रिंग पर सेट करना" पढ़ना चाहिए "सभी को एक कुकी के 'डोमेन' भाग की स्थापना नहीं।" उदाहरण के लिए, कुकी के डोमेन अनुभाग को पूरी तरह से छोड़ने के लिए एक साधारण परीक्षण का उपयोग करना लोकलहोस्ट के लिए काम करता है:((domain && domain !== "localhost") ? ";domain="+domain : "")
L0j1k

33

मैं व्यापक रूप से @Ralph Buchfelder से सहमत हूं, लेकिन यहाँ कुछ प्रयोग किए गए हैं, जब मेरे स्थानीय मशीन (जैसे example.com, fr.example.com, de.example.com) के साथ कई उप-डोमेन के साथ एक प्रणाली को दोहराने की कोशिश कर रहा हूँ ( ओएस एक्स / अपाचे / क्रोम | फ़ायरफ़ॉक्स)।

मैंने 127.0.0.1 पर कुछ काल्पनिक उप-बिंदुओं को इंगित करने के लिए / etc / मेजबान को संपादित किया है:

127.0.0.1 localexample.com
127.0.0.1 fr.localexample.com
127.0.0.1 de.localexample.com

अगर मैं fr.localexample.com पर काम कर रहा हूं और मैं डोमेन पैरामीटर को छोड़ देता हूं, कुकी को fr.localexample.com के लिए सही तरीके से संग्रहीत किया जाता है, लेकिन अन्य उप-डोमेन में दिखाई नहीं देता है।

अगर मैं ".localexample.com" के डोमेन का उपयोग करता हूं, तो कुकी को fr.localexample.com के लिए सही तरीके से संग्रहीत किया जाता है, और यह है अन्य उप डोमेन में दिखाई दे।

यदि मैं "localexample.com" के डोमेन का उपयोग करता हूं, या जब मैं सिर्फ "localexample" या "लोकलहोस्ट" का डोमेन आज़मा रहा था, तो कुकी संग्रहीत नहीं हो रही थी।

अगर मैं "fr.localexample.com" या ".fr.localexample.com" के डोमेन का उपयोग करता हूं, तो कुकी को fr.localexample.com के लिए सही तरीके से संग्रहीत किया जाता है और अन्य उप-डोमेन में अदृश्य रूप से (सही ढंग से) है।

इसलिए आपको डोमेन में कम से कम दो डॉट्स की आवश्यकता सही प्रतीत होती है, भले ही मैं यह नहीं देख सकता कि यह क्यों होना चाहिए।

अगर कोई इसे आज़माना चाहता है, तो यहाँ कुछ उपयोगी कोड है:

<html>
<head>
<title>
Testing cookies
</title>
</head>
<body>
<?php
header('HTTP/1.0 200');
$domain = 'fr.localexample.com';    // Change this to the domain you want to test.
if (!empty($_GET['v'])) {
    $val = $_GET['v'];
    print "Setting cookie to $val<br/>";
    setcookie("mycookie", $val, time() + 48 * 3600, '/', $domain);
}
print "<pre>";
print "Cookie:<br/>";
var_dump($_COOKIE);
print "Server:<br/>";
var_dump($_SERVER);
print "</pre>";
?>
</body>
</html>

30

localhost: आप उपयोग कर सकते हैं: domain: ".app.localhost"और यह काम करेगा। 'डोमेन' पैरामीटर 1 या अधिक बिंदु की जरूरत को कुकी सेट करने के लिए डोमेन नाम में। तो फिर तुम जैसे स्थानीय होस्ट उप डोमेन में काम कर रहे सत्र हो सकता है: api.app.localhost:3000


1
इसके अलावा परीक्षण किया है और एक Node.js सर्वर पर काम कर रहे, एक्सप्रेस 3.x का उपयोग कर, मेंexpress.session({cookie: { domain: '.app.localhost', maxAge: 24 * 60 * 60 * 1000 }})
AmpT

3
यदि आप स्थानीय डोमेन का उपयोग कर रहे हैं, तो इसे एक उत्तर के रूप में चुना जाना चाहिए! उपडोमेन से पहले बिंदी लगाने से मेरी समस्या ठीक हो जाती है।
फॉक्सहाउंडन

1
तो, यह .app.आने वाला कहाँ से आता है? क्या यह कुछ युक्ति का हिस्सा है? और क्या यह सभी गैर-अनुरूपण डोमेन (दो डॉट्स के बिना) के लिए लागू है? इसके अलावा, क्या यह पुराने ब्राउज़रों के साथ काम करेगा? : ^)
user2173353

ओह ... मैं अब समझ गया ... यह केवल ब्राउज़र को मूर्ख बनाने की एक चाल है। ठीक है।
user2173353

14

जब एक कुकी 'लोकलहोस्ट' के स्पष्ट डोमेन के साथ सेट की जाती है ...

सेट-कुकी: नाम = मूल्य; डोमेन = लोकलहोस्ट ; expires = थू, 16-जुलाई -2009 21:25:05 जीएमटी; पथ = /

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

... फ़ॉर्म के डोमेन को रोकने के लिए डोमेन में कम से कम दो (2) या तीन (3) अवधि होनी चाहिए: ".com", ".edu", और "va.us"। कोई भी डोमेन जो सात विशेष शीर्ष स्तर के डोमेन में से एक के भीतर विफल रहता है, नीचे सूचीबद्ध केवल दो अवधियों की आवश्यकता होती है। किसी भी अन्य डोमेन को कम से कम तीन की आवश्यकता होती है। सात विशेष शीर्ष स्तर के डोमेन हैं: "COM", "EDU", "NET", "ORG", "GOV", "MIL", और "INT"।

ध्यान दें कि उपरोक्त अवधि की संख्या संभवतः मानती है कि अग्रणी अवधि की आवश्यकता है। हालांकि इस अवधि को आधुनिक ब्राउज़रों में अनदेखा किया गया है और इसे शायद पढ़ना चाहिए ...

कम से कम एक (1) या दो (2) अवधि

ध्यान दें कि डोमेन विशेषता के लिए डिफ़ॉल्ट मान उस सर्वर का होस्ट नाम है जिसने कुकी प्रतिक्रिया उत्पन्न की

इसलिए लोकलहोस्ट के लिए कुकीज का सेट न होना एक डोमेन विशेषता निर्दिष्ट करने के लिए नहीं है और ब्राउज़र को डिफ़ॉल्ट मान का उपयोग करने दें - ऐसा नहीं लगता है कि डोमेन विशेषताओं में एक स्पष्ट मान है।


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

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

1
डोमेन को छोड़कर (इसे बिल्कुल भी सेट नहीं करना) Chrome को लोकलहोस्ट के लिए कुकी रखने का कारण नहीं बनता है। यह अभी भी इसे अनदेखा करता है। ध्यान दें कि यह केवल "स्थायी" कुकीज़ पर लागू होता है (जो एक समाप्ति तिथि निर्धारित करते हैं), क्योंकि यह लोकलहोस्ट के लिए "सत्र" कुकीज़ पर लटकाएगा (वे जो समाप्ति तिथि निर्धारित नहीं करते हैं)।
त्रियुन्को

3

परिणाम मेरे पास ब्राउज़र द्वारा विविध थे।

Chrome- 127.0.0.1 ने काम किया लेकिन लोकलहोस्ट .localhost और "" ने नहीं किया। फ़ायरफ़ॉक्स-। लोकलहोस्ट ने काम किया लेकिन लोकलहोस्ट, 127.0.0.1, और "" नहीं किया।

ओपेरा, IE, या सफारी में परीक्षण नहीं किया है


3
बस इसे क्रोम V.22.0.1229.94 मीटर के साथ परीक्षण किया गया: एक Domain=पैरामीटर काम दिए बिना लोकलहोस्ट के लिए एक कुकी सेट करना । Domain=भी काम करता है, लेकिन Domain=localhostनहीं करता है।
sleske

3

इस समस्या का निवारण करने में बहुत समय व्यतीत हुआ।

PHP का उपयोग करना, और इस पृष्ठ पर कुछ भी मेरे लिए काम नहीं किया। मुझे अंततः अपने कोड में एहसास हुआ कि PHP के session_set_cookie_params () के लिए 'सुरक्षित' पैरामीटर हमेशा TRUE पर सेट किया जा रहा था।

चूंकि मैं https के साथ लोकलहोस्ट का दौरा नहीं कर रहा था इसलिए मेरा ब्राउज़र कभी कुकी स्वीकार नहीं करेगा। इसलिए, मैंने अपने कोड के उस हिस्से को $ _SERVER ['HTTP_HOST'] 'लोकलहोस्ट' होने या न होने के आधार पर सशर्त रूप से 'सुरक्षित' परम निर्धारित किया। अब अच्छी तरह से काम कर रहा है।

मुझे उम्मीद है इससे किसी को सहायता मिलेगी।


2

यदि आप दूसरे डोमेन से कुकी सेट कर रहे हैं (यानी आप XHR क्रॉस ओरिजिनल रिक्वेस्ट करके कुकी सेट करते हैं), तो आपको यह सुनिश्चित करने की ज़रूरत है कि आप withCredentialsXMLHttpRequest पर जिस विशेषता का उपयोग करते हैं, उसे कुकी के रूप में लाने के लिए सही सेट करें


उसके साथ भी हाँ। यह अभी भी क्रॉस-डोमेन अनुरोधों के साथ काम नहीं करता है। ब्राउज़र - सफारी, IE 11
रोहित कुमार

2

आप का उपयोग कर सकते localhost.orgया बल्कि .localhost.orgयह हमेशा के लिए हल होगा127.0.0.1


1

मेरे पास डोमेन के रूप में 127.0.0.1 का उपयोग करके स्थानीय स्तर पर बेहतर भाग्य परीक्षण था। मुझे यकीन नहीं है कि क्यों, लेकिन मैंने स्थानीयहोस्टल और .localhost, आदि के साथ मिश्रित परिणाम दिए थे।


1

सुझाए गए फ़िक्सेस में से किसी ने भी मेरे लिए काम नहीं किया - इसे शून्य, झूठे, दो बिंदुओं को जोड़ने आदि के लिए काम किया - काम नहीं किया।

अंत में, मैंने अभी अभी कुकी को डोमेन से हटा दिया है अगर यह लोकलहोस्ट है और अब यह क्रोम 38 में मेरे लिए काम करती है

पिछला कोड (काम नहीं किया):

document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';

नया कोड (अब काम कर रहा है):

 if(document.domain === 'localhost') {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';path=/;' ;
    } else {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
    }

1

मेरे पास एक ही मुद्दा था और मैंने किसी भी डोमेन को निर्दिष्ट किए बिना कुकी नाम में 2 डॉट्स डालकर इसे ठीक किया।

set-cookie: name.s1.s2=value; path=/; expires=Sun, 12 Aug 2018 14:28:43 GMT; HttpOnly

1

जब आप उपयोग करते हैं https://<local-domain>और तब एक मुद्दा प्रतीत होता है http://<local-domain>http://साइट के बाद अनुरोध के साथ कुकीज़ नहीं भेजता https://साइट सेट उन्हें। बल पुनः लोड और स्पष्ट कैश मदद नहीं करता है। कुकीज का केवल मैनुअल क्लियरिंग काम करता है। इसके अलावा, अगर मैं उन्हें https://पेज पर क्लियर कर देता हूं , तो http://पेज फिर से काम करना शुरू कर देता है।

"स्ट्रिक्ट सिक्योर कुकीज" से संबंधित लगता है। यहाँ अच्छी व्याख्या । यह 2017-04-19 को क्रोम 58 में जारी किया गया था

ऐसा लगता है कि क्रोम वास्तव में सुरक्षित कुकीज़ और गैर-सुरक्षित कुकीज़ दोनों को रिकॉर्ड करता है क्योंकि यह पता बार आइकन पर क्लिक करने पर पृष्ठ के प्रोटोकॉल के आधार पर सही कुकीज़ दिखाएगा।

लेकिन Developer tools > Application > Cookiesएक ही डोमेन के लिए एक ही नाम की सुरक्षित कुकी होने पर एक गैर-सुरक्षित कुकी नहीं दिखाएगी, और न ही किसी भी अनुरोध के साथ गैर-सुरक्षित कुकी नहीं भेजेगी। यह क्रोम बग की तरह लगता है, या यदि यह व्यवहार अपेक्षित है, तो जब कोई सुरक्षित कुकीज़ को देखने का कोई तरीका होना चाहिएhttp पृष्ठ और यह संकेत दिया जाए कि उन्हें ओवरराइड किया जा रहा है।

वर्कअराउंड का उपयोग विभिन्न नामित कुकीज़ के आधार पर किया जाता है यदि वे किसी http साइट या https साइट के लिए हैं, और उन्हें आपके ऐप के लिए विशिष्ट नाम देना है। एक __Secure-उपसर्ग इंगित करता है कि कुकी को कड़ाई से सुरक्षित होना चाहिए, और यह एक अच्छा अभ्यास भी है क्योंकि सुरक्षित और गैर-सुरक्षित टकराव नहीं होगा। कर रहे हैं अन्य लाभ उपसर्गों भी करने के लिए।

/etc/hostsHttps बनाम http एक्सेस के लिए विभिन्न डोमेन का उपयोग करना भी काम करेगा, लेकिन एक आकस्मिक https://localhostयात्रा http://localhostसाइटों पर काम करने के लिए समान नामों की किसी भी कुकीज़ को रोक देगी - इसलिए यह एक अच्छा समाधान नहीं है।

मैंने Chrome बग रिपोर्ट दर्ज की है


0

document.cookie = valueename + "=" + value + ";" + expire + "; डोमेन =; path = /";

यह "डोमेन =; पथ = /"; डायनामिक डोमेन लेगा क्योंकि इसकी कुकी उपडोमेन में काम करेगी। अगर आप लोकलहोस्ट में टेस्ट करना चाहते हैं तो यह काम करेगा


0

यहां किसी भी जवाब ने मेरे लिए काम नहीं किया। मैंने पृष्ठ में बहुत ही पहली चीज के रूप में अपनी PHP डालकर इसे ठीक किया।

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

से http://php.net/manual/en/function.setcookie.php


हालांकि इस मुद्दे से कोई लेना-देना नहीं है, यह सिर्फ हेडर से पहले किसी अन्य आउटपुट को भेजने की गलती नहीं है
Marnes


0

मैं चारों ओर खेल रहा था।

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=localhost; Path=/

आज की तरह फ़ायरफ़ॉक्स और क्रोम में काम करता है। हालांकि, मुझे इसे कर्ल के साथ काम करने का तरीका नहीं मिला। मैंने Host-Header और --resolve की कोशिश की, कोई किस्मत नहीं, कोई मदद की सराहना की।

हालांकि, यह कर्ल में काम करता है, अगर मैं इसे सेट करता हूं

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=127.0.0.1; Path=/

बजाय। (जो फ़ायरफ़ॉक्स के साथ काम नहीं करता है।)


0

एक अन्य महत्वपूर्ण विवरण, समाप्ति = को निम्न दिनांक समय प्रारूप का उपयोग करना चाहिए: Wdy, DD-Mon-YYYY HH: MM: SS GMT ( RFC6265 - धारा 4.1.1 )।

Set-Cookie:
  name=value;
  domain=localhost;
  expires=Thu, 16-07-2019 21:25:05 GMT;
  path=/

5
-1 कुकीज़ के लिए वर्तमान युक्ति RFC 6265, tools.ietf.org/html/rfc6265 है , जिसमें स्पष्ट रूप से कहा गया है कि 4 अंकों के वर्षों की अनुमति है। इस प्रकार 2-अंकीय वर्षों का उपयोग करना एक बुरा विचार है, जो विभिन्न ब्राउज़र अलग-अलग व्याख्या करेंगे।
साल्स्के

सही बात। रेफरी RFC6265 खंड 4.1.1
ज़ेन गाड़ी

4
सही है, लेकिन जून 2011 में मुझे यह RFC नहीं मिली। इसलिए जब यह जानकारी अब गलत है, तब जब मैंने लिखा था कि यह नहीं था।
१za बजे त्रैलमज्जा

4
इसे मामूली के रूप में न लें, चीजें बदल जाती हैं और हम सभी को यह सुनिश्चित करने में मदद करने की आवश्यकता है कि उत्तर वर्तमान रहें। बस अपने नवीनतम अपडेट के साथ अपने उत्तर को अपडेट करें जो @sleske ने आपको दिया है और उसकी मदद के लिए धन्यवाद।
मैथ्यू पर्डन

0

बहुत प्रयोग और विभिन्न पदों को पढ़ने के बाद, यह काम किया। मैं कई कुकी सेट कर सकता हूं, उन्हें वापस पढ़ सकता हूं और समय को नकारात्मक सेट कर सकता हूं और उन्हें हटा सकता हूं।

func addCookie(w http.ResponseWriter, name string, value string) {
    expire := time.Now().AddDate(0, 0, 1)
    cookie := http.Cookie{
       Name:    name,
       Value:   value,
       Expires: expire,
       Domain:  ".localhost",
       Path:    "/",
    }
    http.SetCookie(w, &cookie)
}

0

मेरे लिए काम करने वाली एकमात्र चीज़ Path=/कुकी पर सेट थी ।

इसके अलावा, पथ विशेषता का डिफ़ॉल्ट मान ब्राउज़र से ब्राउज़र तक भिन्न होता है, हालांकि मैंने उनमें से केवल दो (फ़ायरफ़ॉक्स और क्रोम) का परीक्षण किया था।

Chrome एक कुकी सेट करने का प्रयास करता है जैसा कि है; यदि शीर्ष लेख pathमें विशेषता छोड़ी गई है Set-Cookieतो इसे संग्रहीत और अनदेखा नहीं किया जाएगा।

हालाँकि, फ़ायरफ़ॉक्स एक कुकी को बिना किसी स्पष्ट pathविशेषता के भी संग्रहीत करता है । यह सिर्फ अनुरोधित मार्ग के साथ इसे सेट करता है; मेरा अनुरोध url था /api/v1/usersऔर रास्ता अपने आप तय हो गया था /api/v1

वैसे भी, दोनों ब्राउज़रों ने तब काम किया जब एक स्पष्ट डोमेन के बिना भी pathसेट किया गया था /, Domain=localhostया कुछ और। तो इस तरह से कुछ अंतर हैं कि प्रत्येक ब्राउज़र कुकीज़ कैसे संभालता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.