Gldapo 0.7.1 Released

This release has only one change which fixes an issue with password attributes.

Gldapo 0.7 Released

Gldapo 0.7 (and a corresponding grails plugin) is now available.

This release primarily fixes some bugs with password attributes and brings the following major features/improvements:

• The addition of an LDAP filter DSL (thanks to Siegfried Puchbauer)
• Drastic improvement to the API for creating and moving objects.
• JavaDoc for commonly used classes (thanks to new GMaven features)

Release Notes

Sub-task

• [GLDP-66] - Base the location of entries in the directory on a ‘parent’ directiory rather than the ‘rdn’ attribute
• [GLDP-69] - Make defining a naming attribute mandatory (i.e. throw exception if none defined)
• [GLDP-70] - Add documentation for @GldapoNamingAttribute
• [GLDP-79] - Raise exception if rdn is set with a different naming attribute
• [GLDP-82] - Raise exception if naming attribute is changed directly (i.e. not via move() or replace())
• [GLDP-86] - Create ‘GldapoEntry’ abstract base class and document

Bug

• [GLDP-76] - Converting raw array values to native (groovy) values with schema-custom mapper raises GldapoTypeMappingException
• [GLDP-77] - Reading an entry with a password attribute raises exceptions
• [GLDP-81] - Static properties on schemas are not ignored
• [GLDP-91] - GldapoSynonymFor breaks GldapoNamingAttribute

Improvement

• [GLDP-47] - When moving/replacing an object, the in memory value of the naming attribute should be updated to reflect the change
• [GLDP-58] - Fix JavaDoc generation and use that as the definitive documentation source
• [GLDP-60] - Sanitise API for replacing/moving objects
• [GLDP-72] - Consolidate overloaded rdn setter on schema objects
• [GLDP-73] - Fetch raw values from contexts as objects, not strings
• [GLDP-74] - Implement tests for schema-custom TO FIELD type mappers
• [GLDP-75] - Implement tests for schema-custom TO TYPE type mappers
• [GLDP-87] - Rename ‘rdn’ property to ‘brdn’

New Feature

• [GLDP-41] - Provide way to name object based on particular attribute
• [GLDP-68] - Add a Filter DSL to ease LDAP querying
• [GLDP-71] - Support password type attributes
• [GLDP-78] - Add ‘namingValue’ property to entries
• [GLDP-83] - Add move(String,Object) method to move an object by naming value and parent
• [GLDP-84] - Add replace(String,Object) method to replace an object by naming value and parent
• [GLDP-85] - Add replace() method
• [GLDP-89] - Provide find() and findAll() variants that take a filter builder closure
• [GLDP-90] - Typemapping for Boolean type

Enjoy.

Moving/Replacing entries with Gldapo 0.7

Following on from the previous post, Gldapo 0.7 makes dealing with the location of LDAP objects much easier. This impacts the move() and replace() methods. I'll focus on replace() here, but pretty much everything applies to move().

0.7 introduces a new signature of replace(String namingValue, Object parent). Let's look at some usage then I'll explain.

What we want to do here is replace an object with cn=Luke and sn=Daily with an object with sn=Daley (note: we could do this with a search, mod, save admittedly, but this is just an example).

I am using the person schema class from the previous post.

First, 0.6 style…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)
 
p.replace("cn=Luke")

In 0.7…

def p = new Person(
    sn: "Daley"
)
 
p.replace("Luke", null)

Or…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)
 
p.replace()

Because we now know which attribute defines the name, we don't need to duplicate that information in the replace() call.

The second argument to replace(String,Object) is the parent of the object to replace. Say we wanted to replace an object in a different ou…

p.replace("Luke", "ou=people")

The move(String,Object) method follows similar semantics. Note though that there is no move() method, cause that just wouldn't make sense.

@GldapoNamingAttribute

I've been working on making the way you define the location of an entry object better.

In Gldapo 0.6, this is a bit cumbersome. Let's look at some examples. Here is our schema class in 0.6…

class Person
{
    String cn
    String sn
}

So let's create one of these people in an ou called people…

def p = new Person(
    cn: "Luke"
    sn: "Daley"
    rdn: "cn=Luke,ou=people"
)
p.save()

Obviously, that could be better.

Let's take a look at how this has improved. First of all our schema class redone…

class Person
{
    @GldapoNamingAttribute
    String cn
    String sn
}

And the same create…

def p = new Person(
    cn: "Luke"
    sn: "Daley"
    parent: "ou=people"
)
p.save()

So what has happened?

The @GldapoNamingAttribute annotation

In 0.7, all schema classes must annotate one attribute with @GldapoNamingAttribute. It is a bit of an inconvenience if you never really care about where the object is (say if you are just using Gldapo for authentication), but it does weigh in with significant advantages.

The parent property

The parent property is new in 0.7. It returns a DistinguishedName that is the entry above the entry, relative to the entry's directory.

So the primary way to set an entry's location is to use a combination of setting the objects naming attribute and the parent attribute.

Using rdn

The rdn attribute still exists (though it's name may change before release) and is even improved. You could also create the person like this…

def p = new Person(
    sn: "Daley"
    rdn: "cn=Luke,ou=people"
)
p.save()

That will work just fine. The rdn property is also gettable on objects that were defined using a naming attribute value and a parent.

You must however match the naming attributes. For example, this won't work…

def p = new Person(
    sn: "Daley"
    rdn: "uid=Luke,ou=people"
)
p.save()

This will complain about trying to set a naming attribute called uid, when cn is defined as the attribute.

Note: All these examples assume only one directory is defined, therefore there is no need to specify which directory the entry belongs to when creating.

The current snapshot of Gldapo has this new feature.

The warm blanket of test coverage

A recent email identified that Gldapo struggles to work with password type attributes. I suspected this was going to be the case, but had pushed it aside in the hope that no one would hit the problem until I had time to look at it. Passwords are a bit of a funny case as they aren't really read/write, but there are cases when you do want to read the encrypted password hash.

It turns out that the problem was that I was reading raw context attributes as strings, when I should have been reading them as objects. Passwords seem to be stored as an array of bytes which can't be cast to a string. The fix was not that difficult, but it's fairly low down the stack. Any change that far down could easily have unexpected repercussions.

It pays to have tests

This isn't a new idea by any stretch. But a couple of times I have wondered if I am going a little overboard with the tests for Gldapo. I don't know what my actual coverage percentage is (there is no real solution for Groovy projects built by Maven for coverage at this time) but I suspect/hope that its > 85%. I try to be vigilant about tests for any new feature or change. As an aside, Gldapo development has been a great tool for learning how to test (and coincidentally how much easier testing is with dynamic languages).

The end result

Because of the good test coverage, I was able to make this change and verify that it did not break the public API. I did have to rejig some tests that tested internal API though. This is good news! I know at least this bug fix won't break any Gldapo 0.6 applications when they upgrade to 0.7.