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
