8

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?

Browno
  • 81
  • 1
  • 4
  • I am having this exact issue with same setup: Apache2.2, PHP 5.4.17, Laravel 4.0.x all running on Centos 6.4. Works fine on localhost but on the server IE and Safari do not accept or send any session cookies. Have been puzzled by this all morning... – David Barker Jul 17 '13 at 12:41
  • I am pretty good at troubleshooting session cookies in browsers. This question has me intrigued. I have never worked with Laravel before, but I could more than likely give you an answer if I could reproduce your issue. By default Laravel uses the native session driver so it souldn't be hard to troubleshoot. Either send me a procedure on how to reproduce or maybe give me a link to a page so I can see how it behaves on the different browsers. – Ray Perea Jul 18 '13 at 04:11
  • Hi Ray, I'll put together some additional data for you, specifically the network output on IE and Safari across two test hosts, bear with me. – David Barker Jul 18 '13 at 14:38
  • you need to provide more information about your problem. if you read the session documentation on php.net you will understand that there are many things that can go wrong with sessions in php. it might not even be framework related. i would suggest you turn off auto start and familiarize yourself with [php session configuration](http://php.net/manual/en/session.configuration.php), set the domain name, session name correctly, ensure you have write access to your session storage folder and most importantly, ensure that your stored sessions object classes are loaded before starting the session ! – vortex Jul 24 '13 at 10:53

4 Answers4

16

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

Robbie
  • 17,605
  • 4
  • 35
  • 72
  • This is actually more than likely going to be the problem. The server is on a VM that is sat in a paused state for prolonged periods of time that plays havoc with the clock... I'll try resetting it and see if it helps. – David Barker Jul 24 '13 at 14:12
  • Holy moly. Thank you so much. I've been bashing my head off a brick wall wondering whether I had something wrong in my Laravel setup. I couldn't work it out - and it was purely that my IE9 testing in VirtualBox had the wrong timezone setup and consequently was actually at the completely wrong time. – alexleonard Dec 11 '13 at 11:43
  • this answer saved me hours of search, I have a time logger app with a session expiring after 5 minutes, and the server time was 1 hours late.. – kitensei Feb 03 '15 at 16:40
2

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"');
    }
});
Marcin Nabiałek
  • 109,655
  • 42
  • 258
  • 291
Mārtiņš Briedis
  • 17,396
  • 5
  • 54
  • 76
1

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"

Negar Javadzadeh
  • 325
  • 7
  • 11
0

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

Kat Cox
  • 3,469
  • 2
  • 17
  • 29