Default auth guard is wrong for Laravel 11, config not updating

[sts-ryan-holton]

Description

I've just upgraded my Laravel project to Laravel 11 from Laravel 10. I've flushed caches. I'm getting the error:

There is no role named super_admin for guard web.

Coming from within the RoleDoesNotExist class line 11.

My User model defines HasRoles, and my default auth gaurd in my config file is api, not web. I haven't made any changes to my User model. Someone suggests this but in my project, I wasn't defining this in Laravel 10. So I think this is a bug.

Steps To Reproduce

Myauth.php config:

/*
|--------------------------------------------------------------------------
| Authentication Defaults
|--------------------------------------------------------------------------
|
| This option defines the default authentication "guard" and password
| reset "broker" for your application. You may change these values
| as required, but they're a perfect start for most applications.
|
*/

'defaults' => [
    'guard' => env('AUTH_GUARD', 'api'),
    'passwords' => env('AUTH_PASSWORD_BROKER', 'users'),
],

/*
|--------------------------------------------------------------------------
| Authentication Guards
|--------------------------------------------------------------------------
|
| Next, you may define every authentication guard for your application.
| Of course, a great default configuration has been defined for you
| which utilizes session storage plus the Eloquent user provider.
|
| All authentication guards have a user provider, which defines how the
| users are actually retrieved out of your database or other storage
| system used by the application. Typically, Eloquent is utilized.
|
| Supported: "session"
|
*/

'guards' => [
    'api' => [
        'driver' => 'session',
        'provider' => 'users',
    ],

    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ]
],

Example Application

No response

Version of spatie/laravel-permission package:

6.4.0

Version of laravel/framework package:

11.25

PHP version:

8.3.9

Database engine and version:

MySQL 8

OS: Windows/Mac/Linux version:

Mac

Additional context

My project uses Laravel Sanctum and is an API to a Nuxt front-end. The following in your code:

/**
 * Lookup a guard name relevant for the $class model and the current user.
 *
 * @param  string|Model  $class  model class object or name
 * @return string guard name
 */
public static function getDefaultName($class): string
{
    $default = config('auth.defaults.guard');

    $possible_guards = static::getNames($class);

    // return current-detected auth.defaults.guard if it matches one of those that have been checked
    if ($possible_guards->contains($default)) {
        return $default;
    }

    return $possible_guards->first() ?: $default;
}

$possible_guards appears to return ['web', 'api'] in this order. But changing them around in my config doesn't work. They're always in this order. In addition, my default is sanctum.

[drbyte]

$possible_guards appears to return ['web', 'api'] in this order.

If $possible_guards is not a single value, then it is coming from getConfigAuthGuards():

laravel-permission/src/Guard.php

Lines 41 to 56 in 05f620c

	/**
	* Get list of relevant guards for the $class model based on config(auth) settings.
	*
	* Lookup flow:
	* - get names of models for guards defined in auth.guards where a provider is set
	* - filter for provider models matching the model $class being checked (important for Lumen)
	* - keys() gives just the names of the matched guards
	* - return collection of guard names
	*/
	protected static function getConfigAuthGuards(string $class): Collection
	{
	return collect(config('auth.guards'))
	->map(fn ($guard) => isset($guard['provider']) ? config("auth.providers.{$guard['provider']}.model") : null)
	->filter(fn ($model) => $class === $model)
	->keys();
	}

... which uses collection methods to query and filter (not sort) values coming back from config('auth.guards').

Is your config('auth.guards') being altered by the application anywhere? Or is config('auth.providers') causing an unexpected side-effect when filtering is applied (intended only to rule-out guards for which there is no matching provider, especially to avoid crashes in Lumen)?