directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Pohle <>
Subject Re: [ApacheDS 1.5.1] unable to search for uniqueMember
Date Mon, 08 Oct 2007 14:05:36 GMT
Ok, i see!

I do understand that ApacheDS 1.5.0 was buggy and therefor version 1.5.1 
was released which is stricter regarding search requests.

Is there a way to do that kind of search with a different way within 
Directory Studio? I ask that because I have to handle a large amount of 
LDAP information where I often need to search for such a think like 

More and more often I realize that LDAP is not that "Lightweight" its 
name implies :-)

Sorry for all my questions


Emmanuel Lecharny schrieb:
> Hi,
> 1.5.0 was buggy, so we released 1.5.1
> 1.5.1 is much more strict regarding search requests, and this is why
> what was possible with the old version is not anymore allowad.
> Again, doing a seach with (uniqueMember=uid*) is _not_ allowed by the
> LDAP specification. At best, you should get an empty list.
> Substring search are valid for strings. A DN is not as string.
> On 10/8/07, Markus Pohle <> wrote:
>> Hi Emmanuel,
>> nope sorry - that doesn't make it clearer for me - seems I am too
>> dump...?!??!
>> Why I am able to do such a search for uniqueMember in an ApacheDS
>> Version 1.5.0 and within the snapshot build that Alex made for me some
>> weeks ago?
>> I am totally confused and apologize for that!
>> Markus
>> Emmanuel Lecharny schrieb:
>>> Hi Markus,
>>> the UniqueMember attributeType is a distinguishedName, which is not a
>>> string. Doing a substring search on a non-string object is not
>>> possible (in fact, it should be treated as undefined - see RFC 4511,
>>> par.
>>> You cannot get any result with such a filter :
>>> (uniqueMember=uid=g.kelly*)
>>> Nor can you with :
>>> (ObjectClass=orga*)
>>> Currently, you will simply get a NPE, which will translate to an
>>> Unexpected Exception on the client side.
>>> I'm currently investigating what we should return, and I think the
>>> client should receive an empty result instead of an exception.
>>> I hope it's clear enough
>>> Emmanuel

View raw message