[Support] PHPStan reports Auth::getUser() to return the Ldap User instead of database model

[bertoost]

When I configure Laravel as per documentation, with database fallback support, like this;

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

PHPStan thinks that Auth::getUser() returns an instance of LdapRecord\Models\ActiveDirectory\User::class which is actually not the case and just our own model.

How can we solve this?

Regards, Bert

Environment:

• LDAP Server Type: ActiveDirectory
• LdapRecord-Laravel Major Version: v10
• PHP Version: 8.2 (or 8.3 is same issue)

[stevebauman]

Hey @bertoost,

I don't use PHPStan so I personally have no idea.

This should probably be reported on the PHPStan repo, as we can't control how it interprets the Laravel auth config files.

[bertoost]

Hi @stevebauman That's a bit to easy unfortunately.

Laravel (and thus phpstan, with larastan) expects configuration auth.providers.users.model to be the local model file. So, phpstan also expects that. Therefore, this package (which works great), should respect that also. When using the database fallback option, the model config key should be set to the local model and an additional configuration key should be added for the Ldap model to use.

Example;

'providers' => [
    'users' => [
        'driver' => 'ldap',
        'model' => App\Models\User::class,
        // ...
        'database' => [
            'ldapModel' => LdapRecord\Models\ActiveDirectory\User::class,
            // ...
        ],
    ],
],

Therefore the ldapModel could also live on a level above the database fallback configuration.

[stevebauman]

This has been suggested before, but it doesn't make sense to structure the configuration in this way. Why would configuration of the LdapRecord model reside in the "database" key? LdapRecord provides an LDAP authentication driver first, and a database layer second.

I understand this would make your specific use-case satisfy PHPStan, but I will personally be accountable for documenting this, as well as assisting other developers troubleshoot this in the future.

Auth driver configuration cannot be beholden to a single structure as they vary by implementation.