Ldaprecord-laravel: Relationship returns default Entry class?

[stephancasas]

I'd like to start off by saying that I'm more than happy to send you coffee/beer $$ for your time if you'll drop your Venmo, PayPal or other channel in a message or this thread. You've built an excellent library and deserve to be compensated for it.
#

I've got authentication setup within Laravel and things are working, but I'm trying to get groups configured with relationships to the user class. Following the current documentation for relationships I've configured both the hasMany() and hasMany()->using() relationship in the user and group models.

However, when I use $user->groups()->get() or $group->members()->get() the object returned is a collection of generic LdapRecord\Models\Entry objects. Am I missing something or do I totally misunderstand how this is supposed to be working?

Laravel 7 with OpenLDAP and memberOf OLC enabled

[stevebauman]

Hi @stephancasas, thanks for your kind words! ❤️ I really appreciate it, and I'm glad you find LdapRecord useful!

If you'd prefer to donate any amount off a different platform, I do have PayPal setup. Though, let's get you up and running first!

However, when I use $user->groups()->get() or $group->members()->get() the object returned is a collection of generic LdapRecord\Models\Entry objects. Am I missing something or do I totally misunderstand how this is supposed to be working?

This means you have not defined the proper $objectClasses in your User and Group models.

Default Entry models are returned because LdapRecord could not locate a model setup in your relationship that contains the object classes that are returned from the LDAP search results of the relationship query.

Here is the exact method that attempts to determine which model instance to create for a given object's classes:

https://github.com/DirectoryTree/LdapRecord/blob/7aaa057eee6a364ad96cc4e92634af50d7bfa3fd/src/Models/Relations/Relation.php#L331-L336

---

Let's walk through an example.

Let's say I have a the below Group LdapRecord model with invalid object classes:

class Group extends Model
{
    public static $objectClasses = ['foo', 'bar'];
}

And we have a User model that uses the above Group class in a hasMany relationship:

class User extends Model
{
     // ...

    public function groups()
    {
        return $this->hasMany(Group::class, 'member');
    }
}

When we query the above users groups via a $user->groups()->get(), we will get a collection of Entry models. Why? Because when the LDAP search executes and results are returned, each result will not contain our Group models object classes.

For example, in Active Directory, a Group contains the following object classes:

'objectclass' => [
    'top',
    'group','
],

Not:

'objectclass' => [
    'foo',
    'bar','
],

So LdapRecord will simply return you a default Entry instance.

It works this way because an LDAP relationship can contain many different types of objects. For example, a groups members can be a Contact, Computer, User, or another Group, as shown here:

https://github.com/DirectoryTree/LdapRecord/blob/7aaa057eee6a364ad96cc4e92634af50d7bfa3fd/src/Models/ActiveDirectory/Group.php#L39

So if you pass in multiple models, LdapRecord needs to know which model instance to create for each LDAP entry returned from the underlying search.

I hope this helps! Let me know you need help configuring your models.

There are actually default, pre-defined OpenLDAP models you can extend if you'd like:

https://ldaprecord.com/docs/models/#predefined-models

[stephancasas]

Hello!

Thank you for your swift response, and I apologize for not getting back before the weekend was through.

I would have sworn up, down, and sideways that I checked, double-checked, and triple-checked through every possible configuration of the $objectClasses variables in both the User and Group objects, but sure enough...

Understanding how the relation function is written led me to two issues:

1. The order of the LDAP object classes in the array I declared matched the order presented in DirectoryStudio, not the order that was expressed in LDAPRecord.
2. I retained the camelCase nomenclature of the LDAP object classes when I wrote them into the class definitions (e.g. "groupOfNames," "inetOrgPerson," etc.), so the 'strtolower' callback in the array_map() method resulted in a mismatch.

After reordering the $objectClasses array and dropping the camelCase scheme, everything worked perfectly.

Thank you for pointing me in the right direction! Please enjoy a beer, coffee, or other beverage on me (sent via PayPal)!

[stevebauman]

Ah this is a bug, thanks @stephancasas! Appreciate the report. I'm fixing this right now so casing won't apply in the $objectClasses definition.

[stevebauman]

Ok patch has been pushed -- I'm working on some password change improvements that should be complete today. Once completed, I'll create a new release 👍

[stephancasas]

Outstanding! Thank you for following-up. This is my first actionable bug report, so that’s pretty cool!

[stevebauman]

Happy to help, thanks @stephancasas! I use LdapRecord in production every single day -- so it's one of my top priorities that this project be as bug free as possible.

Please feel free to create issues here if you encounter anything, need help, or think something should work better. I need as much feedback as possible so it can be the best it can be 👍