Laravel Nova

[ale1981]

Hi,

Before I contribute / sponsor and raise an Issue is Laravel Nova supported?

Thanks

[stevebauman]

Hi @ale1981,

Could you elaborate on Laravel Nova support? What are you looking to achieve with Laravel Nova & LdapRecord? Authentication? LDAP management? Etc.

[ale1981]

Hi Steve,

I have the auth working fine it's the action events that don't seem to work, when I add the Actionable trait to the resource I get an LDAP error.

Regards

[stevebauman]

Ok. I'd be able to assist with authentication issues, but unfortunately I have never used Laravel Nova, so I'd be working blind in terms of LDAP management using Nova resources...

[ale1981]

Hi Steve, thanks for the response. I managed to resolve by changing this line in Nova's code when looking at which User model class to use;

    return $this->belongsTo(
        config('auth.providers.'.$provider.'.model'), 'user_id'
    );

to

    return $this->belongsTo(
        config('auth.providers.'.$provider.'.database.model'), 'user_id'
    );

[stevebauman]

That's great @ale1981! Glad you were able to resolve it. I appreciate you posting the solution here for others who may encounter the same issue ❤️

[ale1981]

No problem. I should have said this is inside the user method of \Actions\ActionEvent.php

[frankmichel]

@stevebauman I'd like to chime into this discussion. We are running against the same issues with Laravel Nova. Nova is resolving the user model via the following code:

public static function userModel()
{
    $guard = config('nova.guard') ?: config('auth.defaults.guard');

    $provider = config("auth.guards.{$guard}.provider");

    return config("auth.providers.{$provider}.model");
}

When the LdapRecord\Models\ActiveDirectory\User::class is set in the auth config as the user provider, Nova will run into issues because it will use this user model instead of the App\Models\User::class configured in the database array according to https://ldaprecord.com/docs/laravel/v3/auth/database/configuration

Since the database array is not an official part of the Laravel auth config, there's not a chance Laravel Nova will make any changes to the code above.

So the set-up as described in the "Database Auth Configuration" of the LdapRecord library unfortunately breaks compatibility with Laravel Nova.

Maybe it's possible to turn the config around and make the Eloquent user the default overwriting the Config with an "ldap" array? Just a thought.

'users' => [
    'driver' => 'eloquent',
    'model' => App\Models\User::class,
    'rules' => [],
    'scopes' => [],
    'ldap' => [
        'model' => LdapRecord\Models\ActiveDirectory\User::class,
        'sync_passwords' => false,
        'sync_attributes' => [
            'name' => 'cn',
            'email' => 'mail',
        ],
    ],
],

If you need any more input, please let me know. I'd love to help resolving this.

[stevebauman]

Hey @frankmichel!

This was discussed in a fair bit of detail in this issue: #423

Flipping the config around to your proposed structure would be a major breaking change for LdapRecord-Laravel, and the structure wouldn't make much sense for those configuring a plain LDAP (non-Eloquent based) auth connection, as the driver must be ldap.

Nova could easily support resolving auth user models with a simple callback, providing support to any authentication provider rather than being hard-coded to the Eloquent driver. This pattern has been used many times in several first-party packages (Fortify, Sanctum, Scout, etc.):

Nova::resolveUserModelUsing(function () {
    $guard = config('nova.guard') ?: config('auth.defaults.guard');

    $provider = config("auth.guards.{$guard}.provider");

    return config("auth.providers.{$provider}.database.model");
});

Maybe we can get in touch with them to make it happen?

[frankmichel]

@stevebauman Thanks for the quick reply and the link to the issue with more details. I have read through it and agree somewhat that it would probably be better/easier to solve this within the LdapRecord library instead of having to force other libraries that follow the Laravel convention to implement the resolver. This way it also won't break future third-party packages that follow the convention.

I also understand that you don't want to and cannot introduce breaking changes within your library.

So I am trying to come up with some non-breaking ideas. How about the following approach:

Plain Auth
For "Plain Auth" nothing needs to change. The configuration should be made like documented:

'users' => [
    'driver' => 'ldap',
    'model' => LdapRecord\Models\ActiveDirectory\User::class,
    'rules' => [],
    'scopes' => [],
],

Database Auth
However, for database auth, the following should be an optional approach.

I am not too familiar with the ins and outs of the LdapRecord library. But since the 'database' key must be read by the library, so should an 'ldap' key be readable. So wouldn't it be possible to support both configurations:

'driver' => 'ldap',
'model' => LdapRecord\Models\ActiveDirectory\User::class,
'database' => [...],

as well as

'driver' => 'eloquent',
'model' => App\Models\User::class,
'ldap' => [...], // ldap config here

whereas the LdapRecord library can configure the internals depending on whether a "database" key or an "ldap" key is present. This could solve the issues with third-party packages that rely on the eloquent user model configuration.

Would that be possible?

[stevebauman]

@frankmichel Laravel creates the auth driver instance by its name inside thats provided inside of the configuration, so having driver equal to eloquent will create Laravel's stock Eloquent auth driver, and ldap creates an LdapRecord's auth driver:

LdapRecord-Laravel/src/LdapAuthServiceProvider.php

Lines 53 to 63 in 628e978

	/**
	* Register the LDAP auth provider.
	*/
	protected function registerAuthProvider(): void
	{
	Auth::provider('ldap', function ($app, array $config) {
	return array_key_exists('database', $config)
	? $this->makeDatabaseUserProvider($config)
	: $this->makePlainUserProvider($config);
	});
	}

Laravel then passes that config array of the driver into the callback for creating the provider instance.

We can't hijack the eloquent driver name, otherwise existing eloquent based auth guards would then use LdapRecord unintentionally.

I'm up for attempting to resolve this if there's a clever way, and always open to accepting PR's.

[frankmichel]

@stevebauman Thanks for your feedback! I have come up with an idea, please see #639