[Freeipa-devel] please use DN objects

[John Dennis]

I just saw a commit that had things like this in it:

admin_conn.search_s("cn=ranges,cn=etc,"+self.suffix,

Please don't form DN's using string formatting!

We've had DN objects in the code for a long time now, please use them, 
string formatting is not guaranteed to be correct with respect to DN's.

The correct method would have been [1]:

admin_conn.search_s(str(DN(('cn','ranges'),('cn', 'etc'), self.suffix)))

[1] The use of str() on a DN will no longer be needed when my DN work is 
checked in because all ldap methods will take DN objects natively.

Another possible way to have used a DN would be this less preferred method:

admin_conn.search_s(str(DN("cn=ranges,cn=etc", self.suffix)))

Why is this less preferred? Because if sometime later someone decides to 
parameterize one of the items in the string they might make the 
following mistake:

admin_conn.search_s(str(DN("cn=%s,cn=etc" % my_range, self.suffix)))

And now we've just reintroduced string formatting into something we 
previously carefully expunged string formatting from! Whereas if the 
preferred format was used the programmer would likely have done the 
correct thing, namely:

admin_conn.search_s(str(DN(('cn',my_range),('cn', 'etc'), self.suffix)))

A good way to think of DN's is as a sequence of attribute/value pairs 
because that's what they are [2]. The preferred form makes that explicit 
and helps to prevent future mistakes. A DN object will automatically 
generate a properly escaped string from it's sequence of RDN's (i.e. the 
attribute/value pairs mentioned above [2]) when it's finally passed into 
the ldap library.

[2] Technically a DN is a sequence of RDN's and a RDN is an unordered 
set of AVA's. But in most cases an RDN is a simple attribute/value pair. 
If you want to think of DN's as a sequence of attribute/value pairs it's 
a valid mental shortcut, just be aware there is the possibility for 
greater complexity.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/