[Date Prev][Date Next]
Re: (ITS#3251) ldapsearch and non existing objectclasses
>> A (pedantic) client should first check whether the desired objectClasses
>> are present on the server in the SCHEMA. Then, they can be safely used
>> filters. Likely your slapd is missing any of the above objectclasses in
>> the schame files you're currently loading.
> Then please return an error like "invalid filter". So people even notice
> there's something wrong. Here the ldapsearch returns "success" and an
> error code of "0" - which obviously isn't correct.
Then please emendate draft-ietf-ldapbis-protocol, and rfc2251 (4.5.1.
Search Request) and all other standard track that dictate to evaluate the
filter when testing if an entry complies with it, so that no entry is
returned if the filter evaluates to FALSE or UNDEFINED. The operation
returns 0 because it was successful: no error was encountered, and a
(perfectly legal) undefined filter was supplied.
Technically, we cannot decide that a filter is invalid per-schema before
getting to the entry, because in principle each entry could use its own
subschema. OpenLDAP's slapd does not implement that yet, but this is a
completely unrelated point.
Of course, you can always blame the software for using it incorrectly, and
for not looking at the logs first whenever you encounter a problem, and
for not knowing the documents that dictate how it should behave, but this
is something completely different.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497