[Date Prev][Date Next]
Re: LDAP Search: If filter contains nonexistant attribute, entry will not be returned as a 'hit'
On 7/27/05, Pierangelo Masarati <firstname.lastname@example.org> wrote:
> > Pierangelo Masarati writes:
> >>> (&(objectClass=person)(|(sn=*jere*)(cn=*jere*)(blahblah=*jere*))(mail=*))
> >>> My problem is that if a particular entry does not contain each
> >>> attribute (sn, cn, and blahblah) they will not get returned as a hit.
> >>> The attribute "blahblah" is obviously a nonexistent attribute, but
> >>> being inside an "OR" parenthesis group I would assume that wouldn't
> >>> matter.
> > So would I...
> >> Your assumption is in contrast with the specifications of an LDAP
> >> filter.
> >> If "blahblah" is unknown to the DSA (i.e. it does not have a schema
> >> specification), then the __entire__ OR filter evaluates to UNDEFINED,
> >> according to draft-ietf-ldapbis-protocol.
> > Huh?
> > draft-ietf-ldapbis-protocol-31.txt, 220.127.116.11 SearchRequest.filter says:
> > A filter of the "or" choice is FALSE if all of
> > the filters in the SET OF evaluate to FALSE, TRUE if at least one
> > filter is TRUE, and Undefined otherwise.
> > Think of UNDEFINED as "the server can't tell" in this context. If
> > anything else in the (|...) matches, then the server can tell that the
> > filter matches whether or not the undefined component would match.
> Again apologies. Both Jeremiah and I wrote __OR__, but my mind was
> erroneously thinking __AND__. I definitely need to reboot.
> In fact, OpenLDAP's slapd is correctly treating that filer as valid, and
> returning data if any of the valid portions of the filter match:
> [user@host]$ ldapsearch -x -H ldap://:9011 -b 'dc=example,dc=com' -LLL
> dn: cn=Barbara Jensen,ou=Information Technology
> dn: cn=Bjorn Jensen,ou=Information Technology
> Pierangelo Masarati
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
Thank you both for your replies.
I've done further testing against two different LDAP servers. All my
filters and examples work perfectly fine on a Netscape LDAP server. It
behaves exactly like expected. The second LDAP server is giving me the
trouble though. I've attempted to find what kind of server it is
(searching root/base for "objectclass=*" and looking for vendorName,
etc) but nothing shows up. I'll continue to try to determine which
"brand" of LDAP server it is. Anybody know of any other way to
Another strange example (on the same behaving-improperly server) I've
come across is this:
The following filters work: (work == returns results)
But the following does not: (no results returned)
I have no idea why switching the last two would cause the filter to
suddenly stop returning results.
I'll continue researching as much as I can to find the problem. If
anybody has any ideas on how to hunt it down, or has seen this before,
I'd love any help I could get.