[Date Prev][Date Next]
Re: (ITS#3707) An unknown attribute in presence filter evaluates to (?=false) instead of (?=undefined)
Kurt D. Zeilenga wrote:
>(&) and (|) are, with draft-zeilenga-ldap-t-f, valid filter
>strings. But what filter2bv produces is not a filter string,
>it's a filter diagnostic string.
My suggestion is to use "(&)" and "(|)" both as valid filters __and__ as
filter diagnostics, in order to exploit it as discussed later.
>>I can work this issue around as in slapo-rwm and back-meta, but this
>>would require yet another filter2bv conversion.
>For back-ldap/back-meta, it seems one really needs access to
>filter encoding as it appeared in the request so that it can
>be forwarded intact (it would be nice if we had an ldap_search()
>call where the filter was passed as BER value).
That would be great also for another feature I'm considering (ITS#3711).
>that filter massaging would be a nice feature, you actually
>need both access to filter encoding and another filter2bv
In principle that's correct, and I agree. In practice, filter2bv is
already performed by the frontend, so it wouldn't be required; yet, the
diagnostics make the resulting filter unusable as is in functions that
require the filter in its string representation (like back-ldap and
back-meta, for instance). The use of filter diagnostics like "(&)" and
"(|)" instead of "(?=true)" and "(?=false)" would make the filter yet
clearly identifiable as using t-f tokens, but would also make it
conformant to filter string representations. The use of diagnostics
like "(?=undefined)" and "(?=error)" is acceptable, since it makes the
filter correctly unusable, so that ldap_search() spits it out without
performing the operation. This may be consistent (after my fix) with
back-ldap usage (back-meta is not affected for different reasons).
The current workaround I'm using is:
- call ldap_search(); in case of filtr parsing error:
- look for "(?=" without a preceding "\";
- if they evaluate to "(?=true)" or "(?=false)"
- if the remote server supports it, replace it with "(&)" or "(|)",
- if it doesn't, try a best approximation of ""(objectClass=*)" or
- if it does elavuate to "(?=<somethig else>)" reject the operation.
With the suggested change, I wouldn't need the above, or, alternatively,
to walk the tree representation of the filter, replace the occurrences
of "(?=true)" and "(?=false)", and re-run filter2bv, which was already
called by the frontend. The latter procedure is run by back-meta and
slapo-rwm because they may need to rewrite DN-valued attrs anyway.
The question is:
- is the suggested rearrangement of diagnostics acceptable?
- or, in other terms, should the filter contained in ors_filterstr be
considered a vaild filter string representation if no errors occurred
during its decoding?
back-ldap has ever relied on this assumption, but in case of t-f filters
it's not true, at present.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497