Risposte:
L'attuale specifica dei cookie è RFC 6265 , che sostituisce RFC 2109 e RFC 2965 (entrambi gli RFC sono ora contrassegnati come "Storici") e formalizza la sintassi per l'utilizzo dei cookie nel mondo reale. Si afferma chiaramente:
- introduzione
...
Per motivi storici, i cookie contengono una serie di informazioni sulla sicurezza e sulla privacy. Ad esempio, un server può indicare che un determinato cookie è destinato a connessioni "sicure", ma l'attributo Sicuro non fornisce integrità in presenza di un attaccante di rete attivo. Allo stesso modo, i cookie per un determinato host sono condivisi tra tutte le porte su quell'host, anche se la solita "politica della stessa origine" utilizzata dai browser Web isola i contenuti recuperati tramite porte diverse.
E anche:
8.5. Riservatezza debole
I cookie non forniscono isolamento per porta . Se un cookie è leggibile da un servizio in esecuzione su una porta, il cookie è anche leggibile da un servizio in esecuzione su un'altra porta dello stesso server. Se un cookie è scrivibile da un servizio su una porta, il cookie è anche scrivibile da un servizio in esecuzione su un'altra porta dello stesso server. Per questo motivo, i server NON DOVREBBERO entrambi eseguire servizi reciprocamente diffidenti su porte diverse dello stesso host e utilizzare i cookie per archiviare informazioni sensibili alla sicurezza.
Secondo RFC2965 3.3.1 (che potrebbe o non potrebbe essere seguito dai browser), a meno che la porta non sia esplicitamente specificata tramite il portparametro Set-Cookiedell'intestazione, i cookie potrebbero o non potrebbero essere inviati a nessuna porta.
Il Manuale di sicurezza del browser di Google dice: per impostazione predefinita, l'ambito dei cookie è limitato a tutti gli URL sul nome host corrente e non è associato alle informazioni sulla porta o sul protocollo. e alcune righe più tardi Non c'è modo di limitare i cookie a un solo nome DNS [...] solo allo stesso modo, non c'è modo di limitarli a una porta specifica. (Inoltre, tenere a mente, che IE fa numeri di porta non fattore nella sua politica stessa origine a tutti .)
Quindi non sembra sicuro fare affidamento su comportamenti ben definiti qui.
Questa è una domanda davvero vecchia ma ho pensato di aggiungere una soluzione alternativa che ho usato.
Ho due servizi in esecuzione sul mio laptop (uno sulla porta 3000 e l'altro sul 4000). Quando saltavo tra ( http://localhost:3000e http://localhost:4000), Chrome inseriva lo stesso cookie, ogni servizio non capiva il cookie e ne generava uno nuovo.
Ho scoperto che se ho effettuato l'accesso http://localhost:3000e http://127.0.0.1:4000, il problema è scomparso poiché Chrome ha conservato un cookie per localhost e uno per 127.0.0.1.
Ancora una volta, a questo punto nessuno potrebbe interessarsene, ma è stato facile e utile per la mia situazione.
localhostnon può essere condiviso con 127.0.0.1e viceversa. Ma i cookie sullo stesso host / dominio, indipendentemente dalla porta, sono condivisibili.
Questa è una grande area grigia nel cookie SOP (stessa politica di origine).
Teoricamente, puoi specificare il numero di porta nel dominio e il cookie non sarà condiviso. In pratica, questo non funziona con diversi browser e ti imbatterai in altri problemi. Quindi questo è fattibile solo se i tuoi siti non sono destinati al grande pubblico e puoi controllare quali browser utilizzare.
L'approccio migliore è ottenere 2 nomi di dominio per lo stesso IP e non fare affidamento sui numeri di porta per i cookie.
Un modo alternativo per aggirare il problema è rendere il nome del cookie di sessione correlato alla porta. Per esempio:
Il tuo codice potrebbe accedere alla configurazione del server web per scoprire quale porta utilizza il tuo server e nominare il cookie di conseguenza.
Tieni presente che l'applicazione riceverà entrambi i cookie e devi richiedere quello corrispondente alla tua porta.
Non è necessario avere il numero di porta esatto nel nome del cookie, ma questo è più conveniente.
In generale, il nome del cookie potrebbe codificare qualsiasi altro parametro specifico dell'istanza del server che si utilizza, quindi può essere decodificato dal giusto contesto.
Stavo riscontrando un problema simile durante l'esecuzione (e il tentativo di debug) di due diverse applicazioni Django sulla stessa macchina.
Li stavo eseguendo con questi comandi:
./manage.py runserver 8000
./manage.py runserver 8001
Quando ho effettuato il login nel primo e poi nel secondo ho sempre disconnesso il primo e viceversa.
Ho aggiunto questo sul mio / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Quindi ho avviato le due app con questi comandi:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problema risolto :)
127.0.0.1:8000per uno, localhost:8000per un secondo, e possibilmente ::1:8000(forse [::1]:8080) per un terzo senza mai toccare il file hosts.
::1 app1 app2 app3 app4 app5 appN
È facoltativo
È possibile specificare la porta in modo che i cookie possano essere specifici della porta. Non è necessario, il web server / l'applicazione deve occuparsene.
Fonte: articolo tedesco di Wikipedia , RFC2109 , capitolo 4.3.1
PortparametroSet-Cookienell'intestazione (perché praticamente nessuno lo ha effettivamente utilizzato nella pratica) e rende molto esplicito che i cookie sullo stesso host NON SONO più distinguibili dalle porte.