为什么在切换服务器后 Laravel Sessions 会在 Safari 和 IE 中失败？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17297990/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why would Laravel Sessions fail in just Safari and IE after switching server?
提问by Browno
New VPS server with Webmin, Apache Centos 6, Laravel application and old database schema. All working fine on old shared host, but on VPS for some reason Laravel's Session storage (Laravel 3.0) is no longer working on Safari or Internet Explorer.
带有 Webmin、Apache Centos 6、Laravel 应用程序和旧数据库架构的新 VPS 服务器。在旧的共享主机上一切正常，但在 VPS 上由于某种原因 Laravel 的会话存储（Laravel 3.0）不再在 Safari 或 Internet Explorer 上工作。
It seems that the Session ID is just not saving on the client. Is a good way to force the Laravel Session ID to save on the clients browser?
似乎会话 ID 只是没有保存在客户端上。强制 Laravel 会话 ID 保存在客户端浏览器上是一种好方法吗？
What are the differences between the way Safari/IE store cookies that might be creating this problem, when Chrome/Firefox appear to be working perfectly fine?
当 Chrome/Firefox 似乎工作得很好时，Safari/IE 存储可能导致此问题的 cookie 的方式有什么区别？
回答by Robbie
Cookies can get knickers in a twist if the time/timezone on the server is not correct. Check the timezone / time setting on the server.
如果服务器上的时间/时区不正确，Cookie 可能会变得混乱。检查服务器上的时区/时间设置。
Note that you need to check the actual time/timezone in the OS, not just the timezone in PHP. But you can verify using PHP by setting timezone in PHP (date_default_timezone_set()) to your local time and asking PHP for the date; if it doesn't match then the server is set incorrectly. Note that adjusting the Timezone in PHP to make it look right won't fix the cookie problem, you must set the OS time/timezone correctly using "date" in the OS.
请注意，您需要检查操作系统中的实际时间/时区，而不仅仅是 PHP 中的时区。但是您可以通过将 PHP ( date_default_timezone_set()) 中的时区设置为您的本地时间并向 PHP 询问日期来验证是否使用 PHP ；如果不匹配，则服务器设置不正确。请注意，在 PHP 中调整时区以使其看起来正确不会解决 cookie 问题，您必须使用操作系统中的“日期”正确设置操作系统时间/时区。
Another way of verifying if this is the problem: set a cookies to expire in a year - do they show? If the timezone is wrong then these will show (>timezone difference), but a 2 hour cookie may not (
验证这是否是问题的另一种方法：将 cookie 设置为在一年后过期 - 它们是否显示？如果时区错误，则这些将显示（> 时区差异），但 2 小时 cookie 可能不会（
Reason: As cookies are set using the actual time (i.e. "this cookie expires 25th July 2013 15:13 GMT"). If your local computer is set differently from the server, then the cookie may appear expired before it's sent. Some browsers correct for this (FF used to, Chrome may now also).
原因：因为 cookie 是使用实际时间设置的（即“此 cookie 于 2013 年 7 月 25 日 15:13 GMT 到期”）。如果您的本地计算机与服务器的设置不同，则 cookie 可能在发送之前就已过期。一些浏览器对此进行了纠正（FF 曾经如此，Chrome 现在也可能如此）。
As the thing that changed here is the server, check the time on your server. (Also double check your own computer for good measure).
由于此处更改的是服务器，因此请检查服务器上的时间。（还要仔细检查您自己的计算机以获得良好的测量）。
回答by Mārti?? Briedis
This is a classic IE/Safari cross-domain/iframe problem.
这是一个经典的 IE/Safari 跨域/iframe 问题。
Potential fix for Laravel IE iframe cookie problem (worked for me). Just add this to your App::after filter.
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"');
});
You can even specify, for which route you need this header, for me, it was everything beyond /external/, so the code looks liek this:
您甚至可以指定您需要此标头的路由，对我来说，它是 /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"');
}
});
回答by Kat Cox
You need to check that EVERYTHING on the new server is identical to the old server... an older or newer version of software could do it, maybe even different htaccess settings...
2 other things to consider...
Maybe a file got corrupted during the move...
Or there is something on the server side messing things up... the free hosting company I used to use had popups, and because of those popups you couldn't use a regular site map for google indexing because the popups injected something into your page.
您需要检查新服务器上的所有内容是否与旧服务器相同……旧版本或新版本的软件都可以做到，甚至可能是不同的 htaccess 设置……
另外两件事要考虑……
也许文件得到了在移动过程中损坏了......或者服务器端有什么东西把事情搞砸了......我曾经使用的免费托管公司有弹出窗口，并且由于这些弹出窗口，您无法使用常规站点地图进行谷歌索引，因为弹出窗口注入了一些东西到你的页面中。
I also just found this... Session won't initialize or remember state between requests
我也刚刚发现这个......会话不会初始化或记住请求之间的状态
What I didn't know is, the call to setcookie will automatically prefix the domain with a period (.) for compatibility. Which on a root-level domain name, it will enable this cookie to be accessed on all subdomains. Which, not realizing this, gave me 2 session cookies and a big mixup happened.
There seems to be 2 ways to fix this:
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.
我不知道的是，为了兼容性，对 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.
And this [solved] Sessions sometimes not persisting across requests
