为什么切换服务器后 Laravel 会话会在 Safari 和 IE 中失败？答案

【问题标题】：Why would Laravel Sessions fail in just Safari and IE after switching server?为什么切换服务器后 Laravel 会话会在 Safari 和 IE 中失败？
【发布时间】：2013-06-22 06:55:57
【问题描述】：

带有 Webmin、Apache Centos 6、Laravel 应用程序和旧数据库模式的新 VPS 服务器。在旧的共享主机上一切正常，但由于某种原因在 VPS 上 Laravel 的会话存储（Laravel 3.0）不再适用于 Safari 或 Internet Explorer。

似乎会话 ID 没有保存在客户端上。强制 Laravel 会话 ID 保存在客户端浏览器上的好方法是什么？

当 Chrome/Firefox 看起来运行良好时，Safari/IE 存储 cookie 的方式可能会导致此问题有什么区别？

【问题讨论】：

我在相同的设置下遇到了这个确切的问题：Apache2.2、PHP 5.4.17、Laravel 4.0.x 都在 Centos 6.4 上运行。在 localhost 上工作正常，但在服务器上 IE 和 Safari 不接受或发送任何会话 cookie。整个上午都被这件事弄糊涂了……
我非常擅长对浏览器中的会话 cookie 进行故障排除。这个问题让我很感兴趣。我以前从未与 Laravel 合作过，但如果我能重现你的问题，我很可能会给你一个答案。默认情况下，Laravel 使用本机会话驱动程序，因此不难排除故障。要么向我发送有关如何重现的程序，要么给我一个页面链接，以便我可以查看它在不同浏览器上的行为。
嗨，Ray，我会为你整理一些额外的数据，特别是 IE 和 Safari 上跨两个测试主机的网络输出，请耐心等待。
您需要提供有关您的问题的更多信息。如果您阅读 php.net 上的会话文档，您将了解 php 中的会话可能会出现许多问题。它甚至可能与框架无关。我建议您关闭自动启动并熟悉php session configuration，正确设置域名、会话名称，确保您对会话存储文件夹具有写入权限，最重要的是，确保在开始之前加载您存储的会话对象类会议！

标签： php laravel session-cookies laravel-3 missing-cookies

【解决方案1】：

如果服务器上的时间/时区不正确，Cookie 可能会出现问题。检查服务器上的时区/时间设置。

请注意，您需要检查操作系统中的实际时间/时区，而不仅仅是 PHP 中的时区。但是您可以通过将 PHP (date_default_timezone_set()) 中的时区设置为您的本地时间并询问 PHP 日期来验证是否使用 PHP；如果不匹配，则服务器设置不正确。请注意，在 PHP 中调整时区以使其看起来正确并不能解决 cookie 问题，您必须使用操作系统中的“日期”正确设置操作系统时间/时区。

验证这是否是问题的另一种方法：将 cookie 设置为在一年内过期 - 它们会显示吗？如果时区错误，则会显示（>时区差异），但 2 小时 cookie 可能不会（

原因：由于 cookie 是使用实际时间设置的（即“此 cookie 将于 2013 年 7 月 25 日 15:13 GMT 到期”）。如果您的本地计算机与服务器的设置不同，则 cookie 可能在发送之前就已过期。一些浏览器对此进行了修正（FF 过去可以，Chrome 现在也可以）。

由于这里更改的是服务器，请检查服务器上的时间。（还要仔细检查您自己的计算机是否正确）。

【讨论】：

这实际上很可能是问题所在。服务器位于一个长时间处于暂停状态的虚拟机上，这对时钟造成了严重破坏......我会尝试重置它，看看它是否有帮助。
天哪。太感谢了。我一直把头从砖墙上撞下来，想知道我的 Laravel 设置是否有问题。我无法解决 - 纯粹是因为我在 VirtualBox 中的 IE9 测试设置了错误的时区，因此实际上是在完全错误的时间。
这个答案为我节省了数小时的搜索时间，我有一个会话在 5 分钟后过期的时间记录器应用程序，而服务器时间延迟了 1 小时..

【解决方案2】：

这是一个经典的 IE/Safari 跨域/iframe 问题。

Laravel IE iframe cookie 问题的潜在修复（为我工作）。只需将其添加到您的 App::after 过滤器即可。

App::after(function ($request, $response){
  $response->header('P3P', 'CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS"');
});

您甚至可以指定需要此标头的路由，对我来说，它是 /external/ 之外的所有内容，因此代码看起来像这样：

App::after(function ($request,$response){
    if($request->is('external/*')){
        // IE iframe cookie fix
        $response->header('P3P', 'CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
    }
});

【讨论】：

【解决方案3】：

我有这个问题，我是这样解决的：我的 .htaccess 没有将 example.com 重定向到 www.example.com，我想去的网址没有 www，但我登录的是 www.example.com。

而不是这个：

ajax:{
 url: "https://example.com" + "/user_list"
 }

我用过这个：

ajax:{
 url: "https://" + window.location.hostname + "/user_list"
 }

通过此替换，您将继续使用您输入的任何地址。有无“www”

【讨论】：

【解决方案4】：

您需要检查新服务器上的所有内容是否与旧服务器相同...较旧或较新版本的软件可以做到这一点，甚至可能是不同的 htaccess 设置...
需要考虑的其他 2 件事...
也许文件在移动过程中损坏了...... 或者服务器端有什么东西把事情搞砸了......我曾经使用的免费托管公司有弹出窗口，并且由于这些弹出窗口，您无法使用常规站点地图进行谷歌索引，因为弹出窗口向您的页面注入了一些东西.

我也发现了这个...Session won't initialize or remember state between requests

我不知道的是，对 setcookie 的调用会自动加前缀带有句点 (.) 的域以保持兼容性。哪个在根级别域名，它将使该 cookie 可以在所有子域。哪个，没有意识到这一点，给了我 2 个会话 cookie 和一个发生了大混乱。

似乎有两种方法可以解决这个问题：
Set the cookie configuration value to something else.

Set the domain to "www.example.org" so that it is only available to the root-level domain name.

还有这个[solved] Sessions sometimes not persisting across requests

【讨论】：