Cookie su localhost con dominio esplicito


191

Devo mancare alcune cose di base sui cookie. Su localhost, quando imposto un cookie sul lato server e specifico esplicitamente il dominio come localhost (o .localhost). il cookie non sembra essere accettato da alcuni browser.

Firefox 3.5: ho verificato la richiesta HTTP in Firebug. Quello che vedo è:

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

oppure (quando imposto il dominio su .localhost):

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

In entrambi i casi, il cookie non viene memorizzato.

IE8: Non ho utilizzato alcuno strumento aggiuntivo, ma il cookie non sembra essere memorizzato, perché non viene inviato indietro nelle richieste successive.

Opera 9.64: Sia localhost che .localhost funzionano , ma quando controllo l'elenco dei cookie in Preferenze, il dominio è impostato su localhost.local anche se è elencato sotto localhost (nel raggruppamento dell'elenco).

Safari 4: sia localhost che .localhost funzionano , ma sono sempre elencati come .localhost nelle Preferenze. D'altra parte, un cookie senza un dominio esplicito, mostrato come solo localhost (senza punto).

Qual è il problema con localhost? A causa di un tale numero di incoerenze, ci devono essere alcune regole speciali che coinvolgono localhost. Inoltre, non mi è completamente chiaro perché i domini devono essere preceduti da un punto? RFC 2109 afferma esplicitamente che:

Il valore per l'attributo Dominio non contiene punti incorporati o non inizia con un punto.

Perché? Il documento indica che deve fare qualcosa con la sicurezza. Devo ammettere che non ho letto l'intera specifica (potrei farlo in seguito), ma suona un po 'strano. Sulla base di questo, l'impostazione dei cookie su localhost sarebbe impossibile.


14
Discussione di 6 anni e questo è ancora un problema. Sto usando Chrome v40. Vedi qui .
Gaui,

5
Chrome 43 ... ancora un bug.
Evan Carroll,

4
Chrome 54 qui, NON risolto
Vahid Amiri,

6
Chrome 73 .. sta ancora affrontando lo stesso problema. :(
Code_Crash

2
Qualcuno potrebbe risolverlo? Sempre di fronte allo stesso ***. Vedi questa risposta SO
Bonjour123

Risposte:


236

In base alla progettazione, i nomi di dominio devono avere almeno due punti; altrimenti il ​​browser li considererà non validi. (Vedi riferimento su http://curl.haxx.se/rfc/cookie_spec.html )

Quando si lavora su localhost, il dominio dei cookie deve essere completamente omesso. Basta impostarlo su ""o NULLo FALSEinvece di "localhost"non è sufficiente.

Per PHP, vedere i commenti su http://php.net/manual/en/function.setcookie.php#73107 .

Se si lavora con l'API Servlet Java, non chiamare affatto il cookie.setDomain("...")metodo.


93
Non sono sicuro del motivo per cui tutti lo stiano facendo +1, ho impostato il dominio del cookie su stringa null o false o vuota e non viene ancora salvato se su localhost.
Justin,

5
Non vedo da nessuna parte in RFC6265 i due punti nel dominio: tools.ietf.org/html/rfc6265#section-5.2.3 .Net dice di impostarlo su ".local" per tutti gli host nel tuo dominio locale. Il che sembra coerente con Opera / Safari msdn.microsoft.com/en-us/library/ckch3yd2.aspx~~V~~singular~~3rd
MandoMando

9
@Justin: Hm, probabilmente dovrai omettere completamente il Domain=parametro durante l'impostazione del cookie. Se hai appena impostato il dominio su null o vuoto, forse il tuo framework invierà il Domain=parametro con quel valore, invece di ometterlo? Verificare ad es. Firebug.
sleske,

2
@Ralph, un milione di grazie, questa cosa mi ha fatto impazzire per alcune ore. Se tutto va bene, impostare il dominio su null (sono in uno stack di server .Net) funziona come un incantesimo.
Xose Lluis,

4
Questo è in qualche modo mal scritto. "L'impostazione su una stringa nulla o falsa o vuota" dovrebbe leggere "Non impostare affatto la parte" dominio "del cookie." Ad esempio, l'utilizzo di un semplice test per escludere completamente la sezione del dominio del cookie funziona per localhost:((domain && domain !== "localhost") ? ";domain="+domain : "")
L0j1k

34

Sono ampiamente d'accordo con @Ralph Buchfelder, ma ecco un po 'di amplificazione di questo, sperimentando quando provo a replicare un sistema con diversi sottodomini (come example.com, fr.example.com, de.example.com) sul mio computer locale ( OS X / Apache / Chrome | Firefox).

Ho modificato / etc / hosts per puntare alcuni sottodomini immaginari a 127.0.0.1:

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

Se sto lavorando su fr.localexample.com e lascio fuori il parametro domain, il cookie viene memorizzato correttamente per fr.localexample.com, ma non è visibile negli altri sottodomini.

Se utilizzo un dominio di ".localexample.com", il cookie viene archiviato correttamente per fr.localexample.com ed è visibile in altri sottodomini.

Se uso un dominio di "localexample.com" o quando stavo provando un dominio di "localexample" o "localhost", il cookie non veniva memorizzato.

Se utilizzo un dominio di "fr.localexample.com" o ".fr.localexample.com", il cookie viene memorizzato correttamente per fr.localexample.com ed è (correttamente) invisibile in altri sottodomini.

Quindi il requisito per cui hai bisogno di almeno due punti nel dominio sembra essere corretto, anche se non riesco a capire perché dovrebbe esserlo.

Se qualcuno vuole provarlo, ecco un codice utile:

<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: è possibile utilizzare: domain: ".app.localhost"e funzionerà. Il parametro "dominio" richiede 1 o più punti nel nome del dominio per impostare i cookie. Allora si può avere sessioni di lavoro in tutta sottodomini localhost come ad esempio: api.app.localhost:3000.


1
Testato e funzionante anche su un server node.js, usando Express 3.x, inexpress.session({cookie: { domain: '.app.localhost', maxAge: 24 * 60 * 60 * 1000 }})
AmpT

3
QUESTO dovrebbe essere selezionato come risposta se si utilizzano domini locali! Mettere un punto prima del sottodominio risolve il mio problema.
Foxhoundn,

1
Quindi, da dove .app.proviene questa prependenza ? Fa parte di alcune SPEC? Ed è applicabile a tutti i domini non conformi (quelli senza due punti)? Inoltre, funzionerà con i vecchi browser? : ^)
user2173353

Oh ... ho capito ora ... È solo un trucco per ingannare i browser. OK.
user2173353

14

Quando un cookie è impostato con un dominio esplicito di "localhost" come segue ...

Set-Cookie: nome = valore; dominio = localhost ; scade = Gio, 16-lug-2009 21:25:05 GMT; path = /

... quindi i browser lo ignorano perché non include almeno due punti e non è uno dei sette domini di primo livello appositamente gestiti .

... i domini devono contenere almeno due (2) o tre (3) periodi per impedire i domini del modulo: ".com", ".edu" e "va.us". Qualsiasi dominio che fallisce in uno dei sette domini di primo livello speciali elencati di seguito richiede solo due periodi. Qualsiasi altro dominio richiede almeno tre. I sette domini di primo livello speciali sono: "COM", "EDU", "NET", "ORG", "GOV", "MIL" e "INT".

Si noti che il numero di periodi sopra presuppone probabilmente che sia richiesto un periodo iniziale. Questo periodo è tuttavia ignorato nei browser moderni e probabilmente dovrebbe leggere ...

almeno uno (1) o due (2) periodi

Si noti che il valore predefinito per l'attributo di dominio è il nome host del server che ha generato la risposta del cookie .

Quindi una soluzione alternativa per i cookie che non sono impostati per localhost è semplicemente quella di non specificare un attributo di dominio e lasciare che il browser utilizzi il valore predefinito - questo non sembra avere gli stessi vincoli di un valore esplicito nell'attributo di dominio.


Non ho DV, ma sto indovinando il motivo per cui altri lo hanno fatto perché la tua risposta non aggiunge davvero molto valore. I requisiti dei due periodi e lasciando vuoto l'attributo del dominio sono stati entrambi discussi in altre risposte. Inoltre, le cose che hai aggiunto su un dominio di primo livello sembrano essere errate. Nella mia esperienza non è un requisito.
TTT,

@TTT Non sono sicuro di essere arrivato al punto nella mia risposta in cui dico che dovrebbe essere almeno 1 o due periodi a seconda del TLD perché i periodi iniziali vengono ignorati? Quindi ho fornito alcune informazioni sul problema e ho aggiunto un punto che non credo sia coperto altrove: le regole sono diverse per un dominio esplicito e quello predefinito dal browser. Sembra che mi aggiunga un valore.
Scott Munro,

1
Lasciare il dominio nullo (non impostarlo affatto) NON causa Chrome per mantenere il cookie per localhost. Lo ignora ancora. Si noti che ciò si applica solo ai cookie "permanenti" (quelli che impostano una data di scadenza), poiché si aggancerà ai cookie "di sessione" per localhost (quelli che non impostano una data di scadenza).
Triynko,

3

I risultati sono stati variati dal browser.

Chrome-127.0.0.1 ha funzionato, ma localhost .localhost e "" no. Firefox- .localhost ha funzionato, ma localhost, 127.0.0.1 e "" no.

Non sono stati testati su Opera, IE o Safari


3
Ho appena testato con Chrome V.22.0.1229.94 m: impostare un cookie per localhost senza fornire un Domain=parametro funziona. Domain=funziona anche, ma Domain=localhostnon.
sleske,

3

Ho trascorso molto tempo a risolvere questo problema da solo.

Uso di PHP e nulla in questa pagina ha funzionato per me. Alla fine ho capito nel mio codice che il parametro 'secure' di session_set_cookie_params di PHP era sempre impostato su TRUE.

Dato che non stavo visitando localhost con https, il mio browser non avrebbe mai accettato il cookie. Quindi, ho modificato quella parte del mio codice per impostare in modo condizionale il parametro 'sicuro' basato su $ _SERVER ['HTTP_HOST'] che è 'localhost' o no. Funziona bene ora.

Spero che questo aiuti qualcuno.


2

Se stai impostando un cookie da un altro dominio (ovvero imposti il ​​cookie effettuando una richiesta di origine incrociata XHR), devi assicurarti di impostare l' withCredentialsattributo su true su XMLHttpRequest che utilizzi per recuperare il cookie come descritto qui


si anche con quello. Non funziona ancora con richieste tra domini. Browser - Safari, IE 11
Rohit Kumar

2

è possibile utilizzare localhost.orgo piuttosto .localhost.orgrisolverà sempre a127.0.0.1


1

Ho avuto molta più fortuna testando localmente usando 127.0.0.1 come dominio. Non sono sicuro del perché, ma ho avuto risultati contrastanti con localhost e .localhost, ecc.


1

Nessuna delle correzioni suggerite ha funzionato per me - impostandola su null, false, aggiungendo due punti, ecc. - Non ha funzionato.

Alla fine, ho appena rimosso il dominio dal cookie se è localhost e ora funziona per me in Chrome 38 .

Codice precedente (non funzionava):

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

Nuovo codice (ora funzionante):

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

1

Ho avuto lo stesso problema e l'ho risolto inserendo 2 punti nel nome del cookie stesso senza specificare alcun dominio.

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

1

Sembra che ci sia un problema quando si utilizza https://<local-domain>e quindi http://<local-domain>. Il http://sito non invia cookie con richieste dopo che il https://sito li ha impostati. Forza il ricaricamento e svuota la cache non aiuta. Funziona solo la cancellazione manuale dei cookie. Inoltre, se li deseleziono sulla https://pagina, la http://pagina riprende a funzionare.

Sembra essere correlato a "Cookie sicuri rigorosi". Buona spiegazione qui . È stato rilasciato in Chrome 58 il 19-04-2017.

Sembra infatti che Chrome registri sia i cookie sicuri sia i cookie non sicuri in quanto mostrerà i cookie corretti a seconda del protocollo della pagina quando si fa clic sull'icona della barra degli indirizzi.

Ma Developer tools > Application > Cookiesnon mostrerà un cookie non sicuro quando esiste un cookie sicuro con lo stesso nome per lo stesso dominio, né invierà il cookie non sicuro con qualsiasi richiesta. Questo sembra un bug di Chrome, o se questo comportamento è previsto, dovrebbe esserci un modo per visualizzare i cookie sicuri quando httpsi trovano su una pagina e un'indicazione che vengono sovrascritti.

La soluzione alternativa consiste nell'utilizzare cookie con nomi diversi a seconda che si tratti di un sito http o https e di denominarli specifici per la tua app. Un __Secure-prefisso indica che il cookie deve essere rigorosamente sicuro, ed è anche una buona pratica perché sicuro e non sicuro non si scontreranno. Ci sono altri vantaggi anche per i prefissi.

Anche l'utilizzo di /etc/hostsdomini diversi per l'accesso https rispetto a http funzionerebbe, ma una https://localhostvisita accidentale impedirà a qualsiasi cookie con lo stesso nome di funzionarehttp://localhost siti, quindi questa non è una buona soluzione.

Ho archiviato a segnalazione di bug di Chrome .


0

document.cookie = valuename + "=" + value + ";" + expires + "; domain =; path = /";

questo "dominio =; percorso = /"; assumerà un dominio dinamico poiché il suo cookie funzionerà nel sottodominio. se vuoi testare in localhost funzionerà


0

Nessuna delle risposte qui ha funzionato per me. L'ho risolto mettendo il mio PHP come la primissima cosa nella pagina.

Come altre intestazioni, i cookie devono essere inviati prima di qualsiasi output dallo script (questa è una restrizione del protocollo). Ciò richiede di effettuare chiamate a questa funzione prima di qualsiasi output, inclusi tag e qualsiasi spazio bianco.

Da http://php.net/manual/en/function.setcookie.php


ciò non ha nulla a che fare con il problema, ma non sta facendo l'errore di inviare qualsiasi altro output prima delle intestazioni
Marnes


0

Stavo giocando un po '.

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

funziona su Firefox e Chrome da oggi. Tuttavia, non ho trovato il modo di farlo funzionare con il ricciolo. Ho provato Host-Header e --resolve, senza fortuna, qualsiasi aiuto apprezzato.

Tuttavia, funziona in arricciatura, se impostato su

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

anziché. (Che non funziona con Firefox.)


0

Un altro dettaglio importante, expires = dovrebbe usare il seguente formato di data e ora: Wdy, GG-Mon-AAAA HH: MM: SS GMT ( RFC6265 - Sezione 4.1.1 ).

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

5
-1 L'attuale specifica per i cookie è RFC 6265, tools.ietf.org/html/rfc6265 , che afferma esplicitamente che sono ammessi anni a 4 cifre. Quindi è una cattiva idea usare anni a 2 cifre, che diversi browser interpreteranno in modo diverso.
sleske,

Corretta. Rif. RFC6265 sezione 4.1.1
Carrello Zen

4
Corretto, ma nel giugno 2011 non ho trovato questo RFC. Quindi, mentre queste informazioni ora sono errate, quando l'ho scritto non lo era.
Tralamazza,

4
Non prenderlo in considerazione, le cose cambiano e tutti dobbiamo aiutare a garantire che le risposte rimangano aggiornate. Aggiorna la tua risposta con le ultime informazioni che @sleske ti ha fornito e ringrazilo per il suo aiuto.
Matthew Purdon,

0

Dopo molta sperimentazione e lettura di vari post, ha funzionato. Potrei impostare più cookie, rileggerli e impostare il tempo negativo ed eliminarli.

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

L'unica cosa che ha funzionato per me è stata l'impostazione Path=/del cookie.

Inoltre, il valore predefinito di un attributo path sembra essere diverso da browser a browser anche se ne ho testati solo due (Firefox e Chrome).

Chrome tenta di impostare un cookie così com'è; se l' pathattributo viene omesso Set-Cookienell'intestazione, non verrà memorizzato e ignorato.

Tuttavia, Firefox memorizza un cookie anche senza un pathattributo esplicito . Lo ha appena impostato con il percorso richiesto; l'URL della mia richiesta era /api/v1/userse il percorso era impostato /api/v1automaticamente.

Ad ogni modo, entrambi i browser funzionavano quando pathera impostato /anche senza un dominio esplicito, cioè Domain=localhosto qualcosa del genere. Quindi ci sono alcune differenze nel modo in cui ciascun browser gestisce i cookie.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.