Perhaps extensible matching rules can be used for such corner cases? Alex
On 10/8/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> 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. 4.5.1.7) > > > > > > 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 > > > > > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
