現在のCookieの仕様は RFC 6265 で、これは RFC 2109 および RFC 2965 （両方のRFCが「Historic」としてマークされている）を置き換え、 Cookieの実際の使用法の構文。それは明確に述べています：
- 前書き
...
歴史的な理由から、Cookieには多くのセキュリティとプライバシーの欠陥が含まれています。たとえば、サーバーは、特定のCookieが「安全な」接続用であることを示すことができますが、Secure属性はアクティブなネットワーク攻撃者が存在する場合の整合性を提供しません。 同様に、Webブラウザーで使用される通常の「同じ起源ポリシー」は異なるポートを介して取得されたコンテンツを分離しますが、特定のホストのCookieはそのホストのすべてのポートで共有されます。
そしてまた：
8.5。弱い機密性
Cookieはポートによる分離を提供しません。 Cookieが1つのポートで実行されているサービスで読み取り可能な場合、Cookieは同じサーバーの別のポートで実行されているサービスでも読み取り可能です。 Cookieが1つのポートのサービスによって書き込み可能な場合、Cookieは同じサーバーの別のポートで実行されているサービスによっても書き込み可能です。このため、サーバーは、同じホストの異なるポートで相互に不信なサービスを実行し、Cookieを使用してセキュリティの機密情報を保存することはできません。
RFC2965 3.3.1（ブラウザが続く場合とされない場合がある）によると、ポートがSet-Cookieヘッダーのportパラメーターで明示的に指定されていない限り、Cookieはポートに送信される場合とされない場合があります。
Googleの Browser Security Handbook は次のとおりです：デフォルトでは、Cookieスコープは現在のホスト名のすべてのURLに制限され、ポートまたはプロトコル情報にバインドされていません。と数行後Cookieを単一のDNS名のみに制限する方法はありません[...]同様に、特定のポートに制限する方法はありません。（また、IEはポート番号を同一の発信元ポリシーに考慮しないことに注意してください。）
したがって、ここで明確に定義された動作に依存することは安全ではないようです。
これは本当に古い質問ですが、使用した回避策を追加すると思いました。
ラップトップで2つのサービスを実行しています（ポート3000と4000で1つ）。 （http://localhost:3000とhttp://localhost:4000）の間をジャンプすると、Chromeは同じCookieを渡し、各サービスはCookieを理解せず、新しいCookieを生成します。
http://localhost:3000とhttp://127.0.0.1:4000にアクセスすると、Chromeがlocalhostと127.0.0.1のCookieを保持していたため、問題が解決したことがわかりました。
繰り返しますが、誰もこの時点で気にしないかもしれませんが、それは私の状況に簡単で役に立ちました。
これはCookie SOP（Same Origin Policy）の大きな灰色の領域です。
理論的には、ドメインのポート番号を指定すると、Cookieは共有されません。実際には、これはいくつかのブラウザーでは機能せず、他の問題に遭遇します。したがって、これはサイトが一般向けではなく、使用するブラウザを制御できる場合にのみ実行可能です。
より良い方法は、同じIPに対して2つのドメイン名を取得し、Cookieのポート番号に依存しないことです。
問題を回避する別の方法は、セッションCookieの名前をポート関連にすることです。例えば：
- mysession808ポート8080で実行されているサーバーの場合
- mysession80ポート8000で実行されているサーバーの場合
コードはWebサーバー構成にアクセスして、サーバーが使用するポートを見つけ、それに応じてCookieに名前を付けることができます。
アプリケーションは両方のCookieを受信するため、ポートに対応するCookieをリクエストする必要があることに注意してください。
Cookie名に正確なポート番号を含める必要はありませんが、これはより便利です。
一般に、Cookie名は、使用するサーバーインスタンスに固有のその他のパラメーターをエンコードできるため、適切なコンテキストでデコードできます。
IE 8では、Cookie（localhostに対してのみ検証）がポート間で共有されます。 FF 10ではそうではありません。
読者が各シナリオをテストするための少なくとも1つの具体的なオプションを持つように、この回答を投稿しました。
同じマシン上で2つの異なるDjangoアプリケーションを実行（およびデバッグ）する際に、同様の問題が発生していました。
私はこれらのコマンドでそれらを実行していました：
./manage.py runserver 8000
./manage.py runserver 8001
最初のログインでログインした後、2番目のログインでログインすると、常に最初のログインからログアウトし、その逆も同様でした。
これを/ etc/hostsに追加しました
127.0.0.1 app1
127.0.0.1 app2
次に、これらのコマンドを使用して2つのアプリを開始しました。
./manage.py runserver app1:8000
./manage.py runserver app2:8001
問題が解決しました ：）
オプションです。
Cookieがポート固有になるようにポートを指定できます。 Webサーバー/アプリケーションはこれを気にする必要はありません。
出典： ドイツ語版ウィキペディアの記事 、 RFC2109 、第4.3.1章