[Date Prev][Date Next]
Re: ldapsearch and non existing objectclasses (ITS#3251)
Am Mittwoch, 21. Juli 2004 18:42 schrieb Pierangelo Masarati:
> > Am Mittwoch, 21. Juli 2004 15:21 schrieben Sie:
> >> OpenLDAP's slapd is strongly schema aware. A request for a nonexistent
> >> objectClass (i.e. not defined in the server's cn=subschema entry)
> >> results
> >> in an erroneous filter. The result of negating an erroneous filter is
> >> another error. The right approach to get alal entries is by using the
> >> presence filter '(objectClass=*)', since all entries must have an
> >> objectClass.
> >> This ITS will be closed, since it does not appear to indicate any bug
> >> in the software.
> > The problem is not the use of (objectClass=*). The software is looking
> > for i.e.
> > (&
> > (objectClass=posixGroup)
> > (!( |
> > (objectClass=sambaGroupMapping)
> > (objectClass=gosaApplicationGroup)
> > ))
> > )
> > So, you suggest me to do checks if the objectclasses are present first
> > and then assemble the filters? Problem is that it is non trivial to get
> > the classes from several types/versions of ldap servers.
> > If you refer to objectClass definitions, it is logic for the software,
> > but not
> > a logic result for the person who is editing the filter. Sorry.
> A (pedantic) client should first check whether the desired objectClasses
> are present on the server in the SCHEMA. Then, they can be safely used in
> 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 that
there's something wrong. Here the ldapsearch returns "success" and an
error code of "0" - which obviously isn't correct.