Authentication does not persist when session.driver == 'database'

[vomitHatSteve]

Description

If the session driver is set to database, successful authentication is forgotten, creating an infinite redirection loop.

Reproduction

1. Configure a new Laravel/Auth0 project by following the Laravel webapp quickstart.
2. Configure the database session driver according to Laravel's documentation.
3. Log into your site with your Auth0 account.

Upon signing into Auth0, the browser is thrown into an infinite redirect loop

• localhost/
• localhost/login
• XYZ.auth0.com/authorize?...
• localhost/callback?...

Environment

• auth0/login 5.3.1
• auth0/auth0-php 5.6.0
• laravel 6.6.X
• Mariadb

Other notes

This issue has been noticed before in the auth0-samples repositories (auth0-samples/laravel#10) but was ultimately not resolved.

[joshcanhelp]

@vomitHatSteve - Appreciate the detailed report here, Steve. I'm not entirely sure what's happening here but would hope anything session related would have been fixed in 5.3.x. That said, some of this might come from callback handling that could be improved (see #141). I would look into that callback route and see if you can figure out what's causing a successful login to redirect or what error you're getting back from Auth0.

I'll leave this open in the meantime to hopefully help with troubleshooting.

[vomitHatSteve]

Great! Thank you.

[saltukalakus]

Hi @joshcanhelp , @lbalmaceda as part of a ticket I was able to reproduce the same issue with the reference sample. Let me know if I can help with anything. PS: For this issue I haven't opened an engineering task.

[marlboro]

I am having this same issue. Has anyone managed to get this working?

[joshcanhelp]

@vomitHatSteve @marlboro - Would you be able to give the change-user-model branch a try and see if it works to fix this as well?

https://github.com/auth0/laravel-auth0/tree/change-user-model

We've changed a lot around how the session is handled both in the SDK and this library.

[vomitHatSteve]

I will test as soon as I get a chance. My company has added a whole stack of other priorities in the meantime, so it may be a bit.

[vomitHatSteve]

Ok. Found some time.

In a first test, it still had the infinite redirect. However, I'm not sure if my dependencies are correct.
Running $ composer require auth0/laravel-auth0:dev-change-user-model
returned a "Could not find matching version of package" error, so I ended up manually downloading the repo and switching to that branch.

edit: tried a few alternate methodologies for installing the libraries, and the issue is definitely still occurring

• auth0/login dev-change-user-model##eabad36a
• auth0/auth0-php 7.1.0
• laravel 6.17.1
• Mariadb

[caleuanhopkins]

Hi all, sorry going to piggyback on this ticket as I have the same issue described here. Few things whilst debugging I discovered:

my Auth0CallbackController.php looks like this: (note: i'm using a custom callback for debug purposes only)

    public function callback()
    {
        // Get a handle of the Auth0 service (we don't know if it has an alias)
        $service = \App::make('auth0');

        // Try to get the user information
        $profile = $service->getUser();

        // Get the user related to the profile
        $auth0User = $this->userRepository->getUserByUserInfo($profile);

        if ($auth0User) {
            // If we have a user, we are going to log them in, but if
            // there is an onLogin defined we need to allow the Laravel developer
            // to implement the user as they want an also let them store it.
            $user = $auth0User;
            if ($service->hasOnLogin()) {
                $user = $service->callOnLogin($user);
            }

            //dd($user);
            $test = Auth::login($user, true);
            $user = Auth::user();
        }

        return redirect()->route('home');
    }

$user returns the authenticated user fine. All good there 👍
When I debug Illuminate\Auth\Middleware\Authenticate middleware on the authenticate method, the $guards array is empty which is then filled by the $guards = [null]; code. As a result, the foreach does loop, skips the return as the $this->auth->guard($guard)->check() isn't ran and then triggers the $this->unauthenticated($request, $guards); line. I've chcked my auth.php file and it looks like this:

<?php
return [
    'defaults' => [
        'guard' => 'web',
        'passwords' => 'users',
    ],
    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'token',
            'provider' => 'users',
        ],
    ],
    'providers' => [
        'users' => [
            'driver' => 'auth0'
        ],
        
    ],
    'passwords' => [
        'users' => [
            'provider' => 'users',
            'table' => 'password_resets',
            'expire' => 60,
        ],
    ],
];

The issue may be the fact the $guards array is empty and assuming that with no guard role attached to the user they are unauthenticated

[caleuanhopkins]

Further to this:

In my HomeController.php file i have this setup:

class HomeController extends Controller
{

    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $user = Auth::user();
    }

    /**
     * Show the application dashboard.
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        $user = Auth::user();
    }
}

If I try to call the authenticated user in the __construct() method, Auth::user() always returns null, fails the auth check and therefore triggers the infinite loop. However, if I call Auth::user() in index() method, the $user variable is filled with the authenciated user's data and passes the auth checks.
Keeping in mind Auth0 PHP library has changed the storing of user details for handle scope on scalable infrastructures, is it maybe that when trying to get an Auth0 user model on __construct(), is this too early for the library to get the user model and therefore returning null?

[caleuanhopkins]

@vomitHatSteve I don't know what your setup is however, I have managed to find a solution to my continual looping. I've changed my HomeController.php to this:

class HomeController extends Controller
{
    public $user;
    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware(function ($request, $next) {
            $this->user = Auth::user();
            return $next($request);
        });
    }

    /**
     * Show the application dashboard.
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        dd($this->user);
    }
}

This now manages to find the user successfully and set it to the property in the class. My loops have not stopped and I can re-use this middleware fix to load the auth user in any of my controllers. Hope this helps 👍

[joshcanhelp]

@caleuanhopkins - Big time thank you for the troubleshooting steps here! Is there anything we can do better in this library or documentation to help avoid this in the future?

[joshcanhelp]

@saltukalakus - Are you able to confirm the fix here?

[caleuanhopkins]

@joshcanhelp I think documentation wise the middleware closure I shared above should be highlighted otherwise Laravel Devs will get the continuous loop happening. I actually think this is more a Laravel execution ordering issue rather than Auth0.

Other than that, I can't think of anything. We're actually running this library in production on an auto-scaling microservice platform and haven't had any issues since we discover the fix I shared above. If we find anything I'll be in touch 👍

[christian-at-sevenlab]

Just an update on this. We ran into a similar issue.

Because of the default migration (from the docs https://laravel.com/docs/7.x/session)
expects a user foreign_key. Auth0 is storing the auth0-id (which is not an int), so you have to change the user_id to string.

[marlboro]

Thank you @christian-at-7lab for posting your fix. It worked for me too. This should be mentioned somewhere in the installation tutorial.