【发布时间】：2010-12-09 09:21:51
【问题描述】：
我在一台机器上运行了两个 HTTP 服务。我只想知道他们是否共享他们的 cookie，或者浏览器是否区分两个服务器套接字。
【问题讨论】：
【发布时间】：2010-12-09 09:21:51
【问题描述】：
当前的 cookie 规范是 RFC 6265，它取代了 RFC 2109 和 RFC 2965（这两个 RFC 现在都被标记为“历史”），并正式确定了 cookie 实际使用的语法。它明确指出：
- 简介
...
由于历史原因，cookie 包含许多安全和隐私方面的缺陷。例如，服务器可以指示给定的 cookie 用于“安全”连接，但 Secure 属性在存在活动网络攻击者的情况下不提供完整性。 同样，给定主机的 cookie 在该主机上的所有端口之间共享，即使网络浏览器使用的通常“同源策略”会隔离通过不同端口检索的内容。
还有：
8.5。保密性差
Cookie 不提供端口隔离。如果运行在一个端口上的服务可以读取 cookie，则运行在同一服务器的另一个端口上的服务也可以读取 cookie。如果 cookie 可由一个端口上的服务写入，则该 cookie 也可由运行在同一服务器的另一个端口上的服务写入。因此，服务器不应在同一主机的不同端口上运行相互不信任的服务并使用 cookie 来存储安全敏感信息。
【讨论】：
-
/etc/hosts可用于为127.0.0.1创建比localhost更多的cookie 域
根据RFC2965 3.3.1（浏览器可能会也可能不会），除非通过Set-Cookie 标头的port 参数明确指定端口，cookie 可能会或可能不会发送到任何端口。
Google 的 Browser Security Handbook 说：默认情况下，cookie 范围仅限于当前主机名上的所有 URL - 并且不绑定到端口或协议信息。 以及稍后的一些行 无法将 cookie 限制为仅单个 DNS 名称 [...] 同样，无法将它们限制为特定端口。（另外，请记住，IE 不会将端口号纳入其同源策略完全。）
因此，在这里依赖任何明确定义的行为似乎并不安全。
【讨论】：
-
RFC 6265，它取代了 RFC 2965，消除了
Set-Cookie标头中的Port参数（因为在实践中几乎没有人实际使用它），并且非常明确地表明同一 cookie主机不再可以通过端口区分。 -
如果域中有端口，IE 9 甚至不会在后续请求中将 cookie 发回
-
是否有任何浏览器仍在考虑其 cookie 的 SOP 中的端口？
-
如果域中有端口，Chrome 甚至不会设置 cookie。
这是一个非常老的问题，但我想我会添加一个我使用的解决方法。
我的笔记本电脑上运行了两个服务（一个在端口 3000 上，另一个在 4000 端口上）。
当我在（http://localhost:3000 和http://localhost:4000）之间跳转时，Chrome 会传入同一个 cookie，每个服务都不会理解 cookie 并生成一个新的。
我发现，如果我访问 http://localhost:3000 和 http://127.0.0.1:4000，问题就消失了，因为 Chrome 为 localhost 和 127.0.0.1 保留了一个 cookie。
同样，此时可能没有人关心，但它对我的情况很容易且有帮助。
【讨论】：
-
是的，因为 cookie 与主机/域名相关联，所以
localhost上的 cookie 不能与127.0.0.1共享，反之亦然。但是，无论端口如何，同一主机/域上的 cookie 都是可共享的。 -
当然有。我（可能还有数百万其他开发人员）一直使用 localhost 进行测试。除非添加的端口有所不同：localhost:8080
-
另外，你可以使用 127.0.0.1, 127.0.0.2, 127.0.0.3 等等……它们都是 localhost 的意思。
-
如果您愿意编辑您的主机文件（Unix 上的 /etc/hosts），您可以为 localhost 设置任意数量的有意义的名称。
-
@DavidBalažic 不，“localhost”表示 127.0.0.1。 127.0.0.2 通常没有名字。这些地址是不同的单播地址，被 TCP 协议视为任何不同的单播地址，但它们都是本地的。
这是 cookie SOP（Same Origin Policy）中的一个很大的灰色区域。
理论上，您可以在域中指定端口号，cookie 不会被共享。实际上，这不适用于多个浏览器，您会遇到其他问题。因此，这仅在您的网站不面向公众且您可以控制要使用的浏览器时才可行。
更好的方法是为同一个 IP 获取 2 个域名，而不是依赖于 cookie 的端口号。
【讨论】：
-
不再是灰色地带。 RFC 6265 是当前的 cookie 标准，通过简单地消除使用不同端口在同一主机上分离 cookie 的能力，消除了任何混淆。
解决此问题的另一种方法是使会话 cookie 的名称与端口相关。例如：
- mysession8080 用于在端口 8080 上运行的服务器
- mysession8000 用于在端口 8000 上运行的服务器
您的代码可以访问网络服务器配置以找出您的服务器使用的端口，并相应地命名 cookie。
请记住，您的应用程序将同时接收两个 cookie，并且您需要请求与您的端口对应的一个。
cookie 名称中不需要有确切的端口号，但这样更方便。
一般来说，cookie 名称可以对特定于您使用的服务器实例的任何其他参数进行编码，因此可以通过正确的上下文对其进行解码。
【讨论】：
-
这适用于在不同端口号上共享主机名的相互信任的 Web 服务。但所有与主机相关的 cookie 都将发送到该主机的所有 Web 服务，无论其名称如何。如果主机允许恶意的非特权运营商在不同的端口号上运行 Web 服务，则运营商可以滥用原始 Web 服务客户的浏览器，将所有与主机相关的 cookie（包括秘密 cookie）发送到共享主机的恶意 Web 服务。
在 IE 8 中，cookie（仅针对 localhost 进行验证）在端口之间共享。在 FF 10 中，它们不是。
我已经发布了这个答案，以便读者至少有一个具体的选项来测试每个场景。
【讨论】：
我在同一台机器上运行（并尝试调试）两个不同的 Django 应用程序时遇到了类似的问题。
我使用这些命令运行它们：
./manage.py runserver 8000
./manage.py runserver 8001
当我在第一个登录然后在第二个登录时，我总是退出第一个，反之亦然。
我在我的 /etc/hosts
上添加了这个127.0.0.1 app1
127.0.0.1 app2
然后我用这些命令启动了这两个应用程序：
./manage.py runserver app1:8000
./manage.py runserver app2:8001
问题解决了:)
【讨论】：
-
您可以使用
127.0.0.1:8000一秒钟，localhost:8000一秒钟，也许::1:8000（也许是[::1]:8080）三秒钟，而无需接触主机文件。跨度> -
可以写成一行：
::1 app1 app2 app3 app4 app5 appN
这是可选的。
可以指定端口，因此 cookie 可以是特定于端口的。没必要，Web 服务器/应用程序必须关心这个。
来源：German Wikipedia article，RFC2109，第 4.3.1 章