stevebauman
commented
6 months ago Hey @joakimbergros! Appreciate the detailed issue.
I would personally be against implementing this, as there's simply too many LDAP attributes in each LDAP distro. This was a mistake I made in the predecessor package Adldap2. I created an interface with a ton of methods to unify accessing shared attributes, but I didn't account for the sheer size of attributes available on all different types of objects (probably in the 500-1000 range all said and done). While having autocomplete is nice, I think this is something that devs will have to add themselves if they need.
And to be honest, I also wouldn't want the burden of maintaining this list of attributes for each provider (a massive undertaking) 🙏
joakimbergros
Hi!
I've been using this library now for a few weeks and it's working great but I initially found myself using magic strings a lot for attribute names. I have fixed this by having an enum with the attributes I use which gives me auto-completion and prevents mistyping.
I assume that the default attributes available on a Ldap entry would differ based on the provider, but do you think there would be any benefit to having a similar approach as a part of the core library?
I'm not entirely sure of how the implementation would fit into the library abstraction wise, but I'd be happy to contribute such an implementation for Active Directory specifically if it is of interest.