Laravel Sessions / Auth broken after update - Laravel 6 - php

Question

I recently updated Laravel and dependencies from 5.7 to 6.0 and am having a problem with a user logging into Laravel and the Session persisting throughout the application.
I can log a user in manually using
Auth()->loginUsingId(theID) in a controller where I'm trying to access User data but a user is not logged in throughout the App. I'm wondering if my Sessions are totally broken or if it has something to do with Middleware. I'm using the standard file system method via Laravel for Session storage.
I don't have my routes in Middleware as I want my API routes open and handle permissions within controllers.
This could have to do with some config issue but I just can't seem to find it. I have also tried a fresh download of Laravel 6 and added my code to it but the problem remains.
Didn't post much code because idk what is most relevant but can if it is useful.
kernel.php:
namespace App\Http;
use Illuminate\Foundation\Http\Kernel as HttpKernel;
class Kernel extends HttpKernel
{
/**
* The application's global HTTP middleware stack.
*
* These middleware are run during every request to your application.
*
* #var array
*/
protected $middleware = [
\App\Http\Middleware\TrustProxies::class,
\App\Http\Middleware\CheckForMaintenanceMode::class,
\Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
\App\Http\Middleware\TrimStrings::class,
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
];
/**
* The application's route middleware groups.
*
* #var array
*/
protected $middlewareGroups = [
'web' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
// \Illuminate\Session\Middleware\AuthenticateSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
\Illuminate\Routing\Middleware\SubstituteBindings::class,
],
'api' => [
'throttle:60,1',
'bindings',
],
];
/**
* The application's route middleware.
*
* These middleware may be assigned to groups or used individually.
*
* #var array
*/
protected $routeMiddleware = [
'auth' => \App\Http\Middleware\Authenticate::class,
'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class,
'cache.headers' => \Illuminate\Http\Middleware\SetCacheHeaders::class,
'can' => \Illuminate\Auth\Middleware\Authorize::class,
'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,
'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,
'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
'verified' => \Illuminate\Auth\Middleware\EnsureEmailIsVerified::class,
];
/**
* The priority-sorted list of middleware.
*
* This forces non-global middleware to always be in the given order.
*
* #var array
*/
protected $middlewarePriority = [
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\Authenticate::class,
\Illuminate\Routing\Middleware\ThrottleRequests::class,
\Illuminate\Session\Middleware\AuthenticateSession::class,
\Illuminate\Routing\Middleware\SubstituteBindings::class,
\Illuminate\Auth\Middleware\Authorize::class,
];

Answer 1

I had the same problem thinking it had something to do with Laravel 6. For me it turned out to be that I use a non-standard primary key for my users table, and needed to declare that on the User model.
For session troubleshooting, keep in mind that changes to config/session.php wipe the current session. I found it helpful to run php artisan config:clear and php artisan cache:clear between tests.

Answer 2

So what I eventually discovered is this:
I have an api.php file for all of my api routes. For the most part, I have separate files for each domain-specific route (e.g., api/user.php), and I include these files in the master api.php file.
One of these domain route patterns was "api/settings". When I moved my settings routes into their own file and included it in api.php, that's what broke everything. I have no idea why, but placing the individual routes back in api.php (and not with a separate file include) solved the problem. I imagine it is some sort of routing conflict with Laravel. No idea. That one took me awhile.