laravel / framework

The Laravel Framework.
https://laravel.com
MIT License
32.29k stars 10.94k forks source link

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

Closed abdulkader92 closed 7 years ago

abdulkader92 commented 7 years ago

5.2: #.#.#

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
Dylan-DPC-zz commented 7 years ago

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

laurencei commented 7 years ago

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

laurencei commented 7 years ago

This is probably related: https://github.com/laravel/framework/issues/7549

And this: https://github.com/laravel/framework/issues/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 commented 7 years ago

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: https://github.com/laravel/framework/issues/14385

thecrypticace commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

the present scenario with Google Chrome 60.#:

laurencei commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

zaeemh commented 5 years ago

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 commented 5 years ago

I am using 5.6 version and the issue is still there

fagner-alves commented 5 years ago

Hello good day!

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

zaeemh commented 5 years ago

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

PouriaSeyfi commented 4 years ago

@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 commented 4 years ago

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 ~* "(laravelsession|joomla[a-zA-Z0-9]+|userID|wordpress(?!test)[a-zA-Z0-9]+|wp-postpass|commentauthor[a-zA-Z0-9_]+|woocommerce_cart_hash|woocommerce_items_in_cart|wp_woocommercesession[a-zA-Z0-9]+|sidcustomer|sidadmin|PrestaShop-[a-zA-Z0-9]+)") { set $CACHE_BYPASS_FOR_DYNAMIC 1; set $EXPIRES_FOR_DYNAMIC 0; }

I hope this helps someone :)

Happy coding!```