| Emmanuel Lecharny 2007-11-15, 7:12 pm |
| 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
|