0

Setup:

  • Multiple laravel replicas behind a load balancer in a private network
  • Replicas contact a single master that has the database on the same private network
  • Replicas are configured to use the database session driver
  • Master has the appropriate session table, created with: php artisan session:table
  • Cloudflare fronts the load balancer with https and all the others (incl. the load balancer itself) are http

When I attempt to login, I can see entries being created in the session table (though the IP column being the 10.0.0.0/24 load balancer from the private network), a XXX_session cookie is also created in the browser, but the user is never logged in and gets thrown back to login.

This does not happen if I use the cookie driver instead.

This question and answer sounded promising as it had mentioned editing the session config, but sadly laravel 5.8 detects all items straight from the .env and never falls back to those second default options provided, leaving me with the things I already did as per laravel database session documentation.

Question: What's wrong, is it because laravel writes the private IP instead of the real users IP into the database? if that's the case how do I force it to write the real user IP I get from cloudflare?

Edits:

10/7/2019: Changing the IP to my external IP in the database does not log me in, even if I bypass the load balancer.

stackbox
  • 102
  • 8
  • Laravel should fail back to default options if the `.env` configuration is null or not there at all – Adam Rodriguez Oct 07 '19 at 16:41
  • @adam yes, but my .env is fully filled out on master and replicas (double-checked right now by outputting them with dd() - just in case), that's also confirmed by the entries in the session table of the master, just that the user does not get logged in for some reason, even though the cookie gets set too after the session table entry. – stackbox Oct 07 '19 at 16:58
  • Is the app key the same in all environments? – Adam Rodriguez Oct 07 '19 at 22:20
  • @adam yes it was, I appreciate your help though! see my response for the solution: https://stackoverflow.com/a/58275457/11821602 will mark it solved in 2 days, as it doesn't let me do that just now. – stackbox Oct 07 '19 at 22:59

1 Answers1

3

Thanks to mlewis over at laracasts, this has been solved:

One possibility is if you've changed the id record on the users table to be uuids (string) instead of int, then you'll need to change your sessions table migration to reflect that on the user_id column. Encountered this the other day myself.

If your users table has the id column as uuid(), then the session table column user_id needs to be uuid() too.

stackbox
  • 102
  • 8