PHP 会话不适用于 IE答案

【问题标题】：PHP session doesn't work with IEPHP 会话不适用于 IE
【发布时间】：2010-09-23 07:08:01
【问题描述】：

我有一个使用 php 制作的网站，它在整个网站中使用服务器端会话。
事实上，它是一个用户登录的站点，它取决于会话变量，如果 all 会话变量有问题，则根本不会加载任何页面。

在网站上，有一个 iframe，其中包含来自其他用户的小消息的提要。
这些小消息旁边有可点击的照片，可以打开用户的个人资料。
现在，每个页面都需要一些格式才能在该特定页面上打开用户的个人资料...实际上只有少数问题页面，但这些页面的 onclick 函数格式必须稍有不同，否则它们会中断页面。
所以我在每个页面（$_SESSION["current_page"]）上设置了一个会话变量，让提要知道如何格式化可点击的照片。现在 Firefox、Opera、Chrome、Safari 都可以正常工作。
但是 IE6 和 IE7 在需要特殊格式的页面上存在问题。
因此，在稍微拉扯头发之后，我最终开始从服务器打印我的会话变量。
你瞧，在特殊页面上，($_SESSION["current_page"]) 总是设置为“main”而不是“special1”或“special2”。

我在 Firefox 和我提到的所有其他浏览器中打印了相同的会话变量，它们按预期打印出“special1”或“special2”。
谁能想到一些事情 - 可能与提要在 iframe 中的事实有关？ - 这会导致 IE 以不同的方式处理服务器端会话变量，或者以某种方式在后台静默启动页面“主”？
我已经非常仔细地检查了提要中对页面“main”的任何引用——它似乎没有任何方式加载该页面。

这对我来说没有意义。

【问题讨论】：

对于遇到此问题的其他人，我建议完全关闭 IE 并重新打开它。这发生在我的 IE10 中，我花了大约半个小时尝试了以下所有解决方案，但无济于事。大约十分之一的会话会保持足够长的时间让我登录我的站点，然后再次死亡。重启浏览器后一切正常。

标签： php internet-explorer session

【解决方案1】：

检查服务器机器的名称。 IE 对包含“-”或“_”的机器名称有问题——它们无法维护会话！过去我遇到过两次这个问题，而且我总是需要几周的时间才能弄清楚，我很震惊 IE 还没有修复它。

只需将机器重命名为没有奇怪的字符！如果你只使用url中服务器的IP地址来测试，你就可以让它工作。

【讨论】：

实际上，这是“按预期破坏”：DNS 名称不应包含下划线（根据 RFC）。所有其他浏览器都可以容忍它们，但 IE 以其无限的智慧，只是默默地丢弃了此类网站的 cookie。没有迹象，什么都没有。无价之宝。
那是很棒的知识。最气人的是，连IE的开发者工具都只是安静。
好像我需要另一个讨厌 IE 的理由。我们在我们的网站上有动态子域供客户拥有自己的个人资料页面，并且一切正常，直到演示日 The Boss 输入下划线并且一切都坏了。
老问题，但对于那些今天正在寻找答案的人，我可以确认这是一个可能的原因。在我的项目中，我开始将当前版本保留为机器名称，例如6_3.myproject.com，6_4.myproject.com。一旦我这样做了，我的登录处理脚本中的 Location() 就会停止传递 PHP $_SESSION 信息并开始一个新的 $_SESSION。我花了很多时间尝试所有不同的解决方案都无济于事。阅读这篇文章让我意识到当切换到新的命名约定时 IE 崩溃了。使用 6dot4.myproject.com 效果很好。
11.0.9600.17691 仍然导致它！我刚刚测试过！

【解决方案2】：

IE 在处理 iFrame 时存在 cookie 问题，这可能会导致您提到的会话问题，请查看这些链接

http://adamyoung.net/IE-Blocking-iFrame-Cookies

http://gathadams.com/2007/06/25/how-to-set-third-party-cookies-with-iframe-facebook-applications/

http://nileshtrivedi.in/blog/2008/09/01/iframe-cookies-and-internet-explorer/

【讨论】：

“问题”不是一个正确的总结。 IE 故意限制跨域 IFRAME 中的 cookie，除非存在 P3P 策略。
@EricLaw-MSFT- 有点晚了，但这正好解释了最近的问题。
@Sijin 非常感谢！你拯救了我的一天！

【解决方案3】：

尝试在使用某种监视代理（我使用Fiddler）的同时测试页面，并查看浏览器请求哪些页面。这可能会给你一些关于发生了什么的线索。

另外，尝试捕获来自不同浏览器的请求/响应，看看 IE 的行为有何不同（请求顺序、请求内容？）。

为了查明问题，您可以不使用使用 SESSION 重写代码吗（在其他答案之一中提到过）？也许 IE 访问页面的顺序与其他浏览器不同？也许它不止一次请求主页，这意味着会话变量设置为“主”？没有会话变量，页面不会影响彼此的状态。

【讨论】：

重写网络应用程序并不总是一种选择。不仅如此，它并没有解决原来的问题——只是改变了它周围的一切。肖恩：你有没有找到原因或解决方案？
Kieveli：好点。我想建议更改为 SESSION-less 代码以查看问题是否仍然存在。如果没有，它会提示您将注意力集中在哪里。当然，如果应用几乎在任何地方都使用会话，那么重写它只是为了查明问题是相当低效的。

【解决方案4】：

在大多数情况下，文件开头的这个 php 行就足够了：

header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');

如果不是，IE7你也可以试试：

header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');

header('Set-Cookie: SIDNAME=ronty; path=/; secure');

header('Cache-Control: no-cache');

header('Pragma: no-cache');

如果这不适用于 IE6，您可以使用 GET 参数作为会话 ID：

header('location: land_for_sale.php?phpSESSID='.session_id());

【讨论】：

【解决方案5】：

我想有些人可能会觉得这个问题的解决方案很有趣。 Fiddler 在这里当然有所帮助。感谢 Fiddler，我可以看到我实际上是在点击页面 main.php（因此在目标页面上设置会话变量之后立即设置会话变量），但是在根目录上获得 302 后服务器默认在那里网站。这一切都在后台默默地发生，之前我的 onload="" javascript 运行。

所以我确定这些页面上的某些东西导致了错误，但不是灾难性的。

这里是：<img src= "" >

IE 被空白 src 属性吓坏了，并点击了服务器根目录和默认为页面主目录。我不完全理解这里发生的机制。我也不明白这是否是 IE 的行为方式（毕竟它是格式错误的 img 标签）。这是一个错误吗？

【讨论】：

由于遗留/历史原因，IE 将空 url "" 视为 "/"，这会导致对根 URL 的 HTTP 请求。在您的情况下，这是有问题的，因为该请求会导致设置 cookie，从而更改您的应用程序的状态。
我们只花了 3 天时间将会话问题追溯到此。至少现在我知道为什么了……

【解决方案6】：

我发现您是否在文档顶部添加了 header('P3P: CP="CAO PSA OUR"');。它似乎已经解决了这个问题。

【讨论】：

【解决方案7】：

我遇到了这个问题，这是由于我的开发盒上的日期已过期。 Firefox 不介意，IE 和 chrome 在会话设置后立即将其视为过期。

【讨论】：

【解决方案8】：

我有同样的问题，现在已经解决了。

任何 IMG 标记的空白或空属性值都会导致问题。对我来说，我使用 JavaScript 将 IMG 对象的源更改为空值。这样做也会产生问题。

【讨论】：

【解决方案9】：

如果我理解正确，您是在尝试使用会话变量将数据从页面传递到该页面上 iframe 内的页面吗？这似乎不是一个好方法 - 为什么不直接将 GET 变量传递到 iframe url，即 ?current_page=special1 。我认为这会更可靠，因为它不依赖于会话状态。

还请记住，对于在用户 PC 上打开的同一站点的多个页面（例如，在多个选项卡上），会话变量将是相同的，这可能会导致奇怪的行为。

【讨论】：

【解决方案10】：

会话数据存储在服务器端，而不是客户端。我会检查设置此值的其他页面。

【讨论】：

【解决方案11】：

我在使用 ie7 时遇到了同样的问题，我就是这样做的：

如果您在 Windows Server 中使用 IIS 或 Apache 时遇到此问题，请查看您要重定向的 URL，它的编写方式必须与重定向之前的 URL 相同。

例如： site.com/pages/index.php 重定向到 site.com/Pages/index2.php 正在进行因为 Pages 中的大写字母，所以在 IE7 中丢失会话。

【讨论】：

【解决方案12】：

也许是session.cookie_lifetime。我遇到了同样的问题。我将session.cookie_lifetime: 4500 更新为session.cookie_lifetime:0。这意味着会话 cookie 在浏览器关闭之前永远不会过期。

【讨论】：