@Paul_Fry Okay so that part is okay, have you tested it with different browsers etc? You can use cURL to do testing for cookies since it's easier to debug issues.

curl --cookie "laravel_session=somereallylonglaravelsessiontoken" http://your.app

@Paul_Fry are you using Laravel 4.2 or 5?

I'm not sure what's going on here, but the original error was because I was using Laravel 5 before its release and I forgot to update the index.php

This index.php has the method call that persists the session.

On the other hand if your session is not persisted maybe you are using "array" instead of "cookie" or "file" or the session data is too big to be saved in a cookie. Hope this helps.

Hi Guys,

I'm using a fresh install of 5 with database connection. I've made little to no changes other than simple config stuff.

@bashy i'll test first thing when i'm back in the office.

Cheers

Hi All!

Here's my case: I experienced this session losing problem and I found it out that the dd(...) is the problem. If you just dumping the variable with var_dump(...) everything's fine. Normally $_SESSION won't lost its content if i run die(...). Why Laravel needs to run $app->terminate() or $kernel->terminate() to persist session every single request? As I noticed Auth::user() is persisted across requests.

Please correct me if i wrong.

Best regards

@silence

It is possible that you have the session driver set to 'array', which will not persist the session across requests. If it is, then you'll need to change it to one of the other options in the config/session.php

In my case, the problem was i had files with character encoding UTF8 with BOM.

The BOM was sending before the session start and each time i made a request a new session was started.

The solution for me: I use this command on the directory: find -type f|while read file;do [ "head -c3 -- "$file"" == $'\xef\xbb\xbf' ] && echo "found BOM in: $file";done

And then change the result files to UTF8 without BOM from notepad++.

Hey, guys.

Long story short, you should remember that Laravel saves session variables after the request lifecycle, i.e. after returning the response. So when you do

Session::put('foo', 'bar');
dd(Session::get('foo'));

You will get "bar" string, but

// Session::put('foo', 'bar');
dd(Session::get('foo'));

Will return null, because dd() will break the request lifecycle. And the 'foo' will be available next request if you didn't break the request and did f.e.

Session::put('foo', 'bar');

return Response::json(['hey' => 'you']);

And I would recommend to use f.e. "redis" as a session storage as I do, much faster than a "file".

Hi guys,

I've been struggling with this problem for several days now, with no luck... I'm pretty sure I've read every single post on the internet regarding this topic by now. Quick description : My pages load fine, but post requests (especially ajax ones) randomly trigger a TokenMismatchException. The token is properly passed, but the session token (server side) isn't always consistent from one request to the next.

I've noticed something which I haven't seen anyone mentioning though. To narrow it down, I've been logging data on my requests, especially the cookie values For succeeding requests, it looks like this:

[2015-09-12 17:38:55] local.INFO: $_COOKIE       : Array
(
    [remember_82e5d2c56bdd0811318f0cf078b78bfc] => eyJpdiI6ImNqaVpVZnRUdndVTHJYTitRU3I1YXc9PSIsInZhbHVlIjoiTjVUOWNCNlRrc2NNQzZQZEY2UVhOUWZ6c2E5VUpmSHBUd1wvVU9tWXpjcTgrM0pcL2xZYWl6RTdrVzh2MVNsWDdkdUs4VEZkQW9WY2k1UllCKzVuUlBGNm43enhpVmhUUVY0N3pKOTlQQzBXQT0iLCJtYWMiOiI5YjBmNjJmMDJlZmIxMzI2MjRiMDk4MzRmMjMyMThmZWViODdlNzJiZTJiODBjY2QwMTdhNzVhNTRjZmI3ZWMwIn0=
    [XSRF-TOKEN] => eyJpdiI6Im56Wm1YN3FrUndiT05xdGxvanhaaGc9PSIsInZhbHVlIjoiUWhQb01sMDYybHRWQlpuTUU2YytZSEJ1ZkpMSVB4eWdYZlBPc2FtRXRrNFFuQjRQUEUwMk1yVzJzd21iKzJPRXE1UDZcLzZ6OURFZ2JtdHdMdVVrNDZRPT0iLCJtYWMiOiI0YTQ4MjViMjk1OTYwODVlZjFjZTMyOWZlZjAwYjU1Mjg4MTY4OTQ0YWU4MDdiMzRkMDY2OTg2ZTVkOTk5NWVjIn0=
    [laravel_session] => eyJpdiI6IlAxcmd2MTMyWVVreXlIQW5NR2V3SGc9PSIsInZhbHVlIjoiT1dXSE1RTDc2ODMzcmY3VjBGSWxjOWVNNU5NU0xWek1uZklUbGREQ25GUVZNUldxbjI3QUJxYnJQWWdSZXRtVlBFcWtydktxcm1Mak9HMndjbU9iOFE9PSIsIm1hYyI6ImE0MTQwNjY5ZWIwNDIzODQwYmYxMTQ3MmMzMzZkYWRkZDdjNGM1ZGIzZmYyYjI4M2Q4ZTVlN2E3YjNlOTg0YTQifQ==
)

While for failing requests it looks like this:

[2015-09-12 17:39:11] local.INFO: cookie       : Array
(
    [remember_82e5d2c56bdd0811318f0cf078b78bfc] => eyJpdiI6ImNqaVpVZnRUdndVTHJYTitRU3I1YXc9PSIsInZhbHVlIjoiTjVUOWNCNlRrc2NNQzZQZEY2UVhOUWZ6c2E5VUpmSHBUd1wvVU9tWXpjcTgrM0pcL2xZYWl6RTdrVzh2MVNsWDdkdUs4VEZkQW9WY2k1UllCKzVuUlBGNm43enhpVmhUUVY0N3pKOTlQQzBXQT0iLCJtYWMiOiI5YjBmNjJmMDJlZmIxMzI2MjRiMDk4MzRmMjMyMThmZWViODdlNzJiZTJiODBjY2QwMTdhNzVhNTRjZmI3ZWMwIn0=
    [XSRF-TOKEN] => eyJpdiI6IjJhdlhCcjdqY1M0S0lObWgybUVWalE9PSIsInZhbHVlIjoiMktvTjFGK0ZRa3FJTDczNm40SU54U0MwRlNBdU5tZmtCWEY3YTYyYm5cL1wvTmxCdFNVY1VMVkViTGl3Z0ZMWjAxOGlYS1dhSjVuTWtDdTkxT2lBSlNLdz09IiwibWFjIjoiNGNiYzU5YzcwMDFhYjRlMDQxZDVmMDUyMmNhMDU1OGQyMWEzOGE0NjExOWY3ZGMzYzU0NzcyZTFhMzBkNjdlNSJ9
    [laravel_session] => eyJpdiI6IjJETmtcL2IrZlI1N2RiN3JVbmlVNyt3PT0iLCJ2YWx1ZSI6InBDS0ZiR1wveGdjRVRrNlpQK0trNjM2Tm15XC9cLzRnTGdZM2FSckk3ZVpCVXBLb2lTOFA1OVdkdXp
)

So clearly, the laravel_session cookie received by the server is much shorter for failing requests than for succeeding ones. As I understand, this value will get decrypted and used to rebuild the session token, which then has little chance of matching the expected.

This is as far as I got so far... I get this behavior 80% of the time using php artisan serve and testing on my phone (built-in android 4.1 browser). I've experienced it from dektop firefox as well, but not consistently enough for a repro. Hope this might ring a bell for some of you guys ! I'd hate to have to disable csrf protection because of this.

I had an issue where I had two separate Laravel installs, one on example.com, the other on subdomain.example.com. They were both using the same session cookie name and domain, so every POST request on the subdomain would fail because the CSRF token mismatch. I simply had to change the session cookie name in config/session.php

I had the same problem.

I manualed Session::save() finaly.because I wasted 1 day for it~

httponly is the reason actually. if you used return redirect(a full url) + httponly,laravel will not save session randomly.

possible solution:

• config/session.php path = '/';
• return redirect(absolutly/relative url) not a full url
• Session::save()

Changing the Session Cookie Name to something other than "laravel_session" worked for me.

It also looks like you cant test the session with a dd() since it saves the session after the request/response cycle.

Hullo,

Had this same issue on laravel 5 using homestead. Re-provisioning vagrant fixed this for me.

In my case it was the usage of the "dump"-method to output variables which stopped Laravel from creating and updating the session cookie.

I just ran into this same problem and it kept me searching for a while.

I noticed that there were no Set-Cookie headers being sent in responses, so the laravel_session was never set causing a new session on each request. I noticed that the $response object did have these Set-Cookie headers in it all the way through the middleware stack. So I tried injecting random setcookie() calls in index.php, which led to an error message indicating

ErrorException: Cannot modify header information - headers already sent by (output started at /path/to/my/file/SomeHelper.php:1)

Sure enough, that file had a space before the opening <?php, which may have been (?) echoed, flushing the response and writing headers.

I just wanted to share my experience. I was using L5.2 and added a Route group for the routes with the 'web' middleware. Probably something stupid of me, but hopefully not the only one ;)

Route::group(['middleware' => 'web'], function () {
    // routes
});

My problem with new created sessions was solved by removing the middleware.

I also experienced this issue for several hours. I change the dd() to var_dump(), everything goes well.

Same problem here. Laravel 5.2.32, tried everything from this topic, still doesn't work.

I've create middleware which runs each request (middleware works, session doesn't):

$testing = !is_null(session('test')) ? session('test') : '+';
$testing = $testing.'+';
session()->put('test', $testing);
echo $links;

I always see just two pluses.

All my routes are using web middleware, I've tried files and database to store sessions.

As of v5.2.31 the "web" middleware is applied by default so setting it explicitly on your routes will cause multiple sessions files to be created amongst other issues (so don't set the "web" middleware on your routes anymore, it's already set for you):

https://github.com/laravel/laravel/commit/5c30c98db96459b4cc878d085490e4677b0b67ed

Hey @stan

I'm having a similar issue with Chrome cutting off the end of my cookie requests.

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

• Firefox works fine.
• Chrome only works when I don't have the remember cookie set.
• Chrome will work if I manually delete the cookie, or if I turn off the Encrypt Cookies middleware (making the cookie values significantly shorter, but in turn disabling the security feature).

It seems to be an issue with the length of the cookie request. I've been racking my brain (and Google Search) at this for a week now, not getting any answers. Chrome is trimming my cookies down to 907 characters, yet every resource I find says I'm allowed 4KB.

Since your post seems similar to my issue, I'm just curious if you ever found a solution. Thanks @stan

I had the same issue where the session token was changing all the time on each refresh. The problem in my case was the cookie name and the reason was based on the setup I have below:

We are using docker for the setup.

• We have another Laravel application with url http://laravel1.dev and wanted to setup a new url for the new Laravel application I created to be http://laravel1.dev/reports in docker routing.

• So, when somebody visits the http://laravel1.dev/reports they will see the new application.

• The problem in this case is that in both applications the cookie was set by default to be laravel_session and it was getting confused and was causing the issue to regenerate the session every time.

I replaced the cookie name inside config/session.php to laravel_session_report and the problem was solved.

Hope it helps for anyone else that has this setup.

Hey @poupouxios

I'm only building one laravel app. I tried changing the session cookie cookie name anyway, the same problem happens. In your case, did the cookie cut off like mine?

Hey @natcave

I'm using Chrome in Macbook and it doesn't seem to cut the cookie. Neither in Safari.

Maybe you are trying to store a lot of information in the cookie and the browsers are trimming it?

Hey @poupouxios

That's what I assumed, though I'm not adding any cookies. This happens with Laravel's cookies straight out the box. With Encrypted Cookies it makes the cookie parameters very long. My best guess is Chrome doesn't like it. I only noticed the problem when "Remember Me" is checked because that adds another encrypted cookie to the bunch and Chrome starts trimming in the middle of that cookie request. I went into detail on these posts:

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

http://stackoverflow.com/questions/39430796/chrome-post-cookie-string-returns-to-server-incomplete

Oddly, it hasn't caught the attention of anyone with the same problem. The key factors are Chrome + Laravel + Remember Me + Form Post.

Hello.

I have same problem with Laravel Framework version 5.0.35

routes.php

Route::get('setsession', function (){
    Session::put('current_user', 'Lionel Morrison');
    Session::put('user_id', '12345');

    var_dump(Session::all());
    return;
});

Route::get('getsession', function () {
    var_dump(Session::all());
});

setsession request returns:

array(4) { ["_token"]=> string(40) "ANJtPiDonoNLWXi5N7PG96R7PiiHENZlq5bAzU6m" ["current_user"]=> string(15) "Lionel Morrison" ["user_id"]=> string(5) "12345" ["flash"]=> array(2) { ["new"]=> array(1) { [0]=> string(5) "flash" } ["old"]=> array(0) { } } }

and next getsession requst returns:

array(1) { ["_token"]=> string(40) "QfdoPKPJ66pWeCX8nljHVrQnrM4ltuaT1X6fZNrj" }

+1. my version is 5.2.45

Checkout this thread. I discovered the bug for me was with XAMPP. I switched to Laragon. Problem solved.

https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me

I recently had this issue and the problem may have been a double-bind of the web middleware on a route. You guys should check that. I failed to notice that web was already applied in RouteServiceProvider. After removing 'middleware' => 'web' on my problem routes, this issue went away completely.

In my case, the cookie was missing the app's session cookie randomly. If I just kept refreshing the same page (route) and wrote the $_COOKIE value in a log, sometimes it contained the app's session value, but mostly – not.

The "remember_web" value seemed to be present at all times, no problems with that one...

Also, the value was not just cut off, it was either there whole (in the $_COOKIES array), or wasn't at all. However, there was some cookie length limit at play, as a couple of app's cookie values for the frontend side (JS) got distorted (or were absent).

On some page refreshes all cookies seemed to be received all right, the total cookie length (as presented in $_SERVER['HTTP_COOKIE']) being about 1280-1300. The rest of the refreshes got exactly 1134 bytes of the cookie, which was not complete.

I was testing only with Firefox (54, Linux), so it's not a Chrome error for me. And its Inspector told me that it's sending all the cookie value all right.

Also, no Nginx or Apache is involved, as I'm using Laravel's php artisan serve.

The work-around in my case presented itself by chance, when I wanted to check if the browser is really sending all the cookie correctly, and tried to intercept the request by Fiddler.

Fiddler didn't capture requests to "localhost", so I tried the actual hostname (machine name, as given by hostname command). Well, I couldn't debug the problematic requests this way because using the machine name instead of "localhost" turned out to be a workaround to the problem... No more cookie cutting happens now.

UPDATE. OK, sorry, that was not a work-around after all. I realised that there was another app I was running on "localhost" (nothing to do with the Laravel app), which also stored a few cookie values. So, I opened it also on the machine host, and sure enough – the problems started again once the (common) cookie became longer. Only, now the cookie, when it gets cut off, is always 1126 bytes long (the complete cookie being about 120 bytes long).

So, I can test now with Fiddler, and it looks like the browser is sending the cookie all right, so the problem should be within the web server.