On 22 Apr 2012, at 19:56, Alexei Znamensky wrote: > Hi Peter, > > On 22 April 2012 15:10, Peter Marschall <pe...@adpm.de> wrote: > >> Hi, >> >> On Sunday, 22. April 2012, Alexei Znamensky wrote: >>> it looks like a problem to me, but I might be wrong. It seems >>> that Net::LDAP::FilterMatch doesn't cope with filters of the type: >>> >>> (dn=*) >>> (dn=cn=joe doe,ou=somewhere) >> >> DN is not an attribute, it is the object's name. >> These filters are illegal. >> > > In that case, why does Net::LDAP::Filter constructor accepts such filters > as argument? Shouldn't it moan that this is illegal? It builds an object > out of that filter. If that is not a legal filter, a Filter object should > not be created out of it.
It *is* syntactically valid, and can be encoded into a search filter. *However* it requires the server understands what an attribute called "dn" is. As Peter pointed out, "dn" is not a valid attribute name in standard servers. > I personally can see no reason why we should not be able to perform > searches based on the object name. It seems silly that I can search by > anything else but the very name of the object. It isn't often done, TBH. I suspect that's mostly because you control the matching area in other parts of the search (base DN, scope), and mostly because most uses of the directory just don't care about the entry DNs that much. For other uses, extensible matching is the way to go. Chris
