I think it's great, and I'd gladly use it if it was easily integrated. I wish that the ldap could automatically read in the first and last names as well as any other information that is needed, since I'd rather present a list of first and last names to someone than their login ID (which could be just a bunch of numbers, or in my case, a jumble of letters and numbers). Nobody is going to remember that my Id is "asdloquahdf12" (especially if there are a lot of others with similar starting and ending characters), but if they see Wilson, Derek - they'll know it's me. So, this is great, but it's changing a lot of core files, and not in a way that it would get accepted into the core product, since it changes the return type of the auth event.
I totally agree, plus I don't really expect it to get integrated into the base code, maybe more of an idea of what is wanted.
but until there is AD group filtering, and all relevant fields in auth table are populated from ldap results, I will still need to use the work around that I came up with. At a minimum it would be nice to have the auth table filled with first name, last name, email address.
0
derek-wilson-10759 12 years ago
I think it's great, and I'd gladly use it if it was easily integrated. I wish that the ldap could automatically read in the first and last names as well as any other information that is needed, since I'd rather present a list of first and last names to someone than their login ID (which could be just a bunch of numbers, or in my case, a jumble of letters and numbers). Nobody is going to remember that my Id is "asdloquahdf12" (especially if there are a lot of others with similar starting and ending characters), but if they see Wilson, Derek - they'll know it's me. So, this is great, but it's changing a lot of core files, and not in a way that it would get accepted into the core product, since it changes the return type of the auth event.
replies (1)