Re: (ITS#3785) filter problem on back-meta

[raphael.ouazana@linagora.com]

On Jeu 16 juin 2005 19:37, Pierangelo Masarati a écrit :
>
>> 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
>>> an
>>> 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.

Ok, sorry for the misunderstanding.

>> 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.

Thank you very much, I'll test that as soon as I'm able to.

Raphael Ouazana.