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?
Your application's session configuration file is stored at config/session.php . Be sure to review the options available to you in this file. By default, Laravel is configured to use the file session driver, which will work well for many applications.
Sessions are used to store information about the user across the requests. Laravel provides various drivers like file, cookie, apc, array, Memcached, Redis, and database to handle session data. By default, file driver is used because it is lightweight. Session can be configured in the file stored at config/session.
Is the session of Laravel secure? With Laravel, you can encrypt data with AES-256 and AES-128 using the OpenSSL library. Laravel uses a Message Authentication Code (MAC) to ensure that encrypted values cannot be modified by unauthorized and unwanted parties.
The session "driver" defines where session data will be stored for each request. Laravel ships with several great drivers out of the box: file - sessions will be stored in storage/framework/sessions . cookie - sessions will be stored in secure, encrypted cookies.
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).
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"');
}
});
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With