[Date Prev][Date Next]
Re: (ITS#3785) filter problem on back-meta
> On Jeu 16 juin 2005 19:14, Pierangelo Masarati a écrit :
>> Assuming that no objectClass "dummy" exists, that bit of the filter
>> doesn't pass filter mapping validation, so it cannot be rewritten into
>> LDAP filter from the parsed form.
> Yes, objectClass "dummy" doesn't exist.
>> As such, the operation is ignored. I
>> realize this is not the expected behavior, so I plan to modify the code
>> such that Undefined is treated like FALSE (i.e. it gets replaced by
>> "(!(objectClass=*))"), to obtain a behavior that is consistent with that
>> of local databases.
> You mean "(|(objectClass=*))", don't you ?
No, I exactly mean "(!(objectClass=*))"; I think this is the closest
equivalent to an UNDEFINED filter in terms of response behavior. Or, if
the remote server supports it, "(|)". So you filter, which in slapd's
internal representation was being presented as
"(|(objectClass=*)(?=undefined))" is now being propagated as
"(|(objectClass=*)(!(objectClass=*)))", which is equivalent to
"(objectClass=*)" according to <draft-ietf-ldapbis-protocol>, because
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.
Of course, this implies that if a bit of the OR filter is Undefined
because some schema knowledge is absent, now back-meta will essentially
ignore that bit, potentially resulting in a search that is different from
the desired one. This highlights the need that proxy DSAs know all the
essential details of the schema of the remote server(s) they're proxying.
> Why did it work with OL2.2.6 ?
Because filter checking was much less pedantic, I assume.
In any case, the problem should now be fixed in HEAD in back-meta,
back-ldap and in slapo-rwm (it affected all of them, since they basically
do the same sort of checking). I'm about to backport this to 2.2.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497