Alex Karasulu wrote:
> Hi,
>
hi,

from the top of my head, I _think_ that we should treat bad values as
Undefined values and treat the filters accordingly to the RFC. This
should solve the problems you are describing. I don't think we are
handling Undefined values, or may be I'm wrong ?
> ApacheDS will normalize filter values before it attempts a search.
> When it does this some filter values will not normalize if incorrect
> resulting in an exception.  For example the member attribute which
> should be a distinguishedName may not be properly formulated due to a
> bad search request.  ApacheDS will return an error instead of
> attempting the search because an exception results when trying to
> parse and normalize the DN in the NormalizationInterceptor.  BTW a
> completely unrelated error message is returned resultCode: loopDetect
> (54).
>
> We have to step back and ask ourselves if this is the right behavior
> we want.  Most LDAP servers will still attempt the search even with
> bad values in the filter assertions in which case the search returns
> with a SUCCESS resultcode yet no entries are returned.
>
> Do we want to enable users to toggle this strict requirement in the
> NormalizationInterceptor with some configuration parameter?
>
> Do we want, in addition, to change the default to simply ignore bad
> assertion values and continue to attempt a search with those bad
> values?  If we're thinking about allowing users to disable schema
> checking at various levels then I think we need to allow for relaxing
> filter normalization.
>
> Alex
>
>


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[ Post a follow-up to this message ]