Laravel -- when I use huge requests I lose session auth

[abdulkader92]

5.2: #.#.#

• PHP version: 5.6.30
• Database Driver & Version: 5.1.73

Description:

|I used Laravel 5.2 version, I noticed that my website user Auth session lost when I used multi requests in great speed, Laravel saves the sessions in storage framework. the problem is maybe because the Laravel recreate another session file in the storage.

1. note 1: sometimes when I use google chrom button I get the same problem.
2. note 2: my website get another old session when I use back google chrom button
3. note 3: the problem is not fixed

• the questions:

• 1- Why Laravel create new Sessoin file and why don't delete the old one?

• 2- Why Laravel lost Auth Session?

• 3- Why laravel get another old user session (huge problem)

[Dylan-DPC-zz]

This repo is for bug tracking. Use the forums or slack channel for solving your issue

[laurencei]

@Dylan-DPC - this is a known issue - I'll find the ticket...

[laurencei]

This is probably related: #7549

And this: #8172

@abdulkader92 - the best options are to upgrade to Laravel 5.4, ensure you are using php artisan config:cache - and to use a different session driver, probably Redis or something.

Doing all that will likely resolve the problem.

[sisve]

This is unrelated to the session driver; Laravel does not support concurrent session requests. Upgrading to 5.4 or changing session driver will not change this. All session drivers have the same problem, they read the payload, let the request execute, then write back the entire payload which will overwrite any changes a concurrent request has made.

Ref: #14385

[thecrypticace]

Yep, I discovered this too. If the session data is small enough the problem isn't likely to appear but as soon as largish data gets stored in the session it can randomly happen. PHP itself doesn't really support concurrent session requests either which is why PHP's native sessions use file locks. The unfortunate downside to this being that requests stall until others are done.

The only possible solution I can think of requires timestamp's on session save (maybe even saving separate timestamped items for all top-level keys stored) and merging changes if the read / write timestamps don't match. How to properly merge data though would almost certainly be a rather tricky thing to solve if it is solvable at all.

[Roemerb]

I had this problem once in an application that relied on large image files. The error you get is very confusing. I eventually figured it out and increasing my PHP max upload size solved the problem.

[laurencei]

@Roemerb - that is a separate issue. I did a PR for that back in 5.3 I think.

If you include \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class, in your Middleware - it detects that situation.

[abdulkader92]

the present scenario with Google Chrome 60.#:

• The (A) user logged in. if he request any link a lot (concurrent), then he will lose authentication user
• Then (B) user logged in. if he request any link a lot (concurrent), then he will get user (A) authentication (dangerous) or maybe he will lose his authentication user
  the problem is not fixed
  Does aravel 5.2.# have any problems with session file driver?
  on the other hand
  Can I use this for my issue https://github.com/rairlie/laravel-locking-session

[laurencei]

@abdulkader92 - I've never heard of UserB getting UserA's session. I dont see how that is possible... do you have any replication of that?

[sisve]

@abdulkader92 To begin; Laravel 5.2 is no longer supported. You're supposed to upgrade to 5.4 and retry if your issue persist there.

Second, your initial issue does not mention a user getting someone else's session details at all. Are you sure about this? We would need a way to reproduce the issue to be able to fix it, this includes source code required, knowing what setup you have, webserver and operating system you use, if you're calling another Laravel/Lumen site over an api, etc.

[themsaid]

Closing this issue for now, please try to recreate a behaviour on a supported version 5.4 and open a new issue with exact description since this issue is a bit confusing.

[iabdelhay]

@abdulkader92 hey, did you find any solution for the issue which user A getting wrong session details or someone else's session details.

because i'm facing the same problem right now.

[hrvali]

I stored large data in the session and the session is lost randomly!

• use laravel 5.5.4
• SESSION_DRIVER=file

[zaeemh]

the present scenario with Google Chrome 60.#:

• The (A) user logged in. if he request any link a lot (concurrent), then he will lose authentication user
• Then (B) user logged in. if he request any link a lot (concurrent), then he will get user (A) authentication (dangerous) or maybe he will lose his authentication user
  the problem is not fixed
  Does aravel 5.2.# have any problems with session file driver?
  on the other hand
  Can I use this for my issue https://github.com/rairlie/laravel-locking-session

@abdulkader92 . hi. did u manage to fix it because I am facing the same issue and this is actually dangerous

[zaeemh]

I am using 5.6 version and the issue is still there

[fagner-alves]

Hello good day!

Has anyone got solution on user B getting the user session to? I'm having this problem.

[zaeemh]

Hi @fagner-alves , I changed from nginx to apache and the issue is now resolved for me.

[PouriaSeyfi]

@zaeemh can you describe that?
we have this problem and we use nginx.
but we are not sure this is the best for us.

[Belezalab-Develop]

I had this weird problem with Sessions in Laravel and couldn't find the solution anywhere. I finally figured it out and I thought that I would share, hoping that it may help someone in the future.

Problem: Engintron configuration micro-caching mixing up session IDs

Solution: Change session cookie name from laravel_session to userID

Full Story:

Problem: The problem was only really noticeable for me with the login process as this is where the sessions were the most important. I noticed that if two users logged in at the same time or nearly the same time, then they would switch identities or the latter would take the identity as the earlier user. I also noticed that the latter would take the session cookie of the former when logged in as that user.

Configuration: Laravel 6.2, PHP 7.2, and Engintron to integrate NGINX to cPanel/WHM

Reason: What was happening here was that the sessions were being cached and the latter user was taking the cached version to log in.

Here is part of the default configuration of Engintron's proxy params dynamic.
code
# CMS (& CMS extension) specific cookies (e.g. Joomla, K2 for Joomla, WordPress, WooCommerce, PrestaShop etc.) if ($http_cookie ~* "(joomla_[a-zA-Z0-9_]+|userID|wordpress_(?!test_)[a-zA-Z0-9_]+|wp-postpass|comment_author_[a-zA-Z0-9_]+|woocommerce_cart_hash|woocommerce_items_in_cart|wp_woocommerce_session_[a-zA-Z0-9]+|sid_customer_|sid_admin_|PrestaShop-[a-zA-Z0-9]+)") { set $CACHE_BYPASS_FOR_DYNAMIC 1; set $EXPIRES_FOR_DYNAMIC 0; }
code
Notice that laravel_session is nowhere in there. Therefore, Engintron will microcache any laravel session Cookie and, under these configurations, you could be allowing a user to wrongfully login to another account.

Solution:

There are two ways to solve this. You could adjust the configurations on your server or within your app.

A) Within Laravel:

Change config/session.php line 127 from:
'cookie' => env( 'SESSION_COOKIE', Str::slug(env('APP_NAME', 'laravel'), '_').'_session' ),

to

'cookie' => 'userID',

B) On the server:

Or simply add laravel_session or whatever you are naming your app's cookies within the list of specific cookies like so:

if ($http_cookie ~* "(laravel_session|joomla_[a-zA-Z0-9_]+|userID|wordpress_(?!test_)[a-zA-Z0-9_]+|wp-postpass|comment_author_[a-zA-Z0-9_]+|woocommerce_cart_hash|woocommerce_items_in_cart|wp_woocommerce_session_[a-zA-Z0-9]+|sid_customer_|sid_admin_|PrestaShop-[a-zA-Z0-9]+)") {
set $CACHE_BYPASS_FOR_DYNAMIC 1;
set $EXPIRES_FOR_DYNAMIC 0;
}

I hope this helps someone :)

Happy coding!```