Re: (ITS#3707) An unknown attribute in presence filter evaluates to (?=false) instead of (?=undefined)

[ando@sys-net.it]

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

>But given
>that filter massaging would be a nice feature, you actually
>need both access to filter encoding and another filter2bv
>function.
>  
>
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 "(|)", 
respctively
  - if it doesn't, try a best approximation of ""(objectClass=*)" or 
"(!(objectClass=*))", respectively
- 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.

p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497