Why would Laravel Sessions fail in just Safari and IE after switching server?

Question

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.

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?

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?

Answer 1

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.

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.

And this [solved] Sessions sometimes not persisting across requests

Answer 2

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.

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.

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 (

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).

As the thing that changed here is the server, check the time on your server. (Also double check your own computer for good measure).

Answer 3

This is a classic IE/Safari cross-domain/iframe problem.

Potential fix for Laravel IE iframe cookie problem (worked for me). Just add this to your App::after filter.

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:

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"');
    }
});

Answer 4

I have this problem and I solve it like this: my .htaccess doesn't redirect example.com to www.example.com and my url that I want to go doesn't have www but I was login in www.example.com.

Instead of this:

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

I used this:

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

With this replacement, you will continue with any address you have entered. With or without "www"