【问题标题】:Why difference in localhost vs 127.0.0.1 regarding SESSIONS为什么 localhost 与 127.0.0.1 关于会话的差异
【发布时间】:2012-05-19 08:51:04
【问题描述】:

我想知道为什么这两个会话存在差异?如果我有一个登录表单并将会话传递到一个页面(即:settings.php)。如果我有localhost/settings.php,如果我转到不同的页面并返回,会话将起作用。但如果是127.0.0.1/settings.php,会话将在第一次通过时工作,然后如果我重定向到其他地方并返回,它就不再存在了。

这是否也发生在其他人身上?还是这只是我?

谢谢

【问题讨论】:

  • Session... 是客户端的 cookie,不是吗?我可能是错的,但我认为cookie严格映射到域名并且没有被浏览器发送到127.0.0.1,因为cookie域是localhost。我的意思是,从浏览器的角度来看,它看起来像是跨域请求。

标签: php session localhost


【解决方案1】:

也许这会有所帮助: http://www.issociate.de/board/post/179979/Cookie_Problems_on_Localhost.html

'localhost' 和任何 ip 都不被接受为有效 cookie 中的域标识符(根据 RFC)。

和 127.0.0.1 != 浏览器的本地主机。浏览器不会发送从 127.0.0.1 设置的 cookie 到 localhost,因为它们是不同的域。

附言实际上,一个 IP 上可以有多个域。当然,出于安全原因,浏览器不能完全发送所有 cookie(想象一下,浏览器可以将来自您网站的 cookie 发送到具有相同 ip 的虚拟主机上的所有网站)。

【讨论】:

    【解决方案2】:

    由于@true 的回答中提到的问题,在我们的开发中,我们通常会创建一个像 dev.localhost.net 这样的假本地域,并使用 hosts 文件将其映射到机器 IP 地址或 127.0.0.1。这有助于解决会话/cookie 问题。

    【讨论】:

    • 这对开发人员非常有用,但对 UI 自动化测试人员来说效果不佳。修改 hosts 文件通常不是由多个团队共享的 CI/CD 管道盒的选项。我发现的最佳解决方法是在浏览器和实际测试环境之间放置一个嵌入式(如:由测试本身启动和控制)代理服务器。然后可以将代理配置为在内部将 dev.localhost.net 的 HTTP 请求重定向到 127.0.0.1,而不涉及主机文件。
    猜你喜欢
    • 2014-08-10
    • 2017-01-14
    • 1970-01-01
    • 2014-04-23
    • 2011-11-15
    • 1970-01-01
    • 2020-12-17
    • 1970-01-01
    • 2015-08-04
    相关资源
    最近更新 更多