| Request | LDAP User Folder -- bug report -- by Mark Hammond |
| Posted on | Jun 1, 2005 4:15 am |
| Subscribe |
| Comment by Mark Hammond on Jul 30, 2005 7:44 pm | |
|
That is great - thanks! Please do consider the hatchet buried - I'm very happy to just get back to the issues themselves! Thanks, Mark |
|
|
|
| Comment by Jens Vagelpohl on Jul 30, 2005 4:10 pm | |
|
By the way, the fix is in CVS and will be part of 2.6beta3. |
|
|
|
| Resolve by Jens Vagelpohl on Jul 30, 2005 4:08 pm | |
|
Well, I found a better argument for extending the search filter that is used for the ZMI-based user search: It is nonobvious to the admin that a user he can look up fine via the search on the Users tab cannot log in at all because the object classes don't match what's specified on the Configure tab. The possible confusion is worse than the confusion over no search results if the object classes on the Configure tab have been mistyped or wrongly specified. When no results are returned there is actually a hint given on the Users tab to check the object classes value on the Configure tab. If you had phrased it like this instead of "too many users are showing up" I might have done it quicker ;) Hatchet buried? jens |
|
|
|
| Reject by Jens Vagelpohl on Jul 23, 2005 7:39 pm | |
|
Since the OP doesn't seem to be interested anymore this issue is closed. |
|
|
|
| Comment by Jens Vagelpohl on Jun 8, 2005 5:50 am | |
|
One solution might be to add a checkbox to the search form which will apply the filter if it is checked, and not if it is not. Comments? |
|
|
|
| Comment by Mark Hammond on Jun 5, 2005 3:23 am | |
|
I was searching for users and received >1000 results, of which about 2% were actually users. I don't think that the solution is to simply present the full (say) 3000 results and make the user hunt for the 20 valid records. I understand that a diagnostic function to search the entire tree would be useful, but can't see a valid justification for a "user search" knowingly returning non-users. Note that we are actually implementing our own tools and obviously we will ensure these only return users for user searches - so I dont really care. I have been attempting to help you and your users but it seems my efforts only waste both our time. Its probably best if I keep such observations to myself and my code in future. Cheers, Mark |
|
|
|
| Comment by Jens Vagelpohl on Jun 4, 2005 6:34 am | |
|
On 1 Jun 2005, at 11:38, JTracker wrote: > So I configured my LDAPUserFolder to use "dc=mycompany,dc=com" as > the base for users, expecting that all users in the tree would be > returned. Instead I received an error from the provider that more > than 1000 entries had been returned. You do realize that Craptive Directory is unique in having such a ridiculously low result set limit, right? IMHO the answer is not one of working around it in the client software, but configuring the directory server to allow more results to be pushed out... |
|
|
|
| Comment by Mark Hammond on Jun 1, 2005 6:38 am | |
|
I've no problem keeping things the way they are, but I'll explain my concern. I was considering an Active Directory setup like many of the Microsoft documentation examples - org units "Sales" and "Engineering", each with a "People" container. so we have, eg, "ou=People,ou=Sales,dc=mycompany,dc=com" and "ou=People,ou=Engineering,dc=mycompany,dc=com" - but we want to allow access to users from both. So I configured my LDAPUserFolder to use "dc=mycompany,dc=com" as the base for users, expecting that all users in the tree would be returned. Instead I received an error from the provider that more than 1000 entries had been returned. |
|
|
|
| Comment by Jens Vagelpohl on Jun 1, 2005 4:58 am | |
|
So far I had not put in the filter out of the belief that if you enter the wrong object class values in the configuration people would at least be able to look them up by searching for a record through the ZMI interface. Matter of fact I find myself doing that all the time when I don't remember what the correct object classes are. Just from my own experience, I'd rather keep it the way it is. |
|
|
|
| Initial Request by Mark Hammond on Jun 1, 2005 4:15 am | |
|
I believe findUser should include self._user_objclasses in the filter string it builds - at least in cases where no search value is specified. At the moment, if you try and set the "user base" to be the base DN of the site (ie, remove the "OU=People" prefix), then search for users, you will get every record in the AD used rather than being restricted to objectClass=people. Happy to help with a patch to this, but not sure what semantics are desired. |
