Process values in template, alias filter

[bersace]

The need is to process LDAP values while rendering role or grant parameters. This would looks like:

- role:
    name: '{cn.slugify()}'

The trick is to subclass string values with a extended class implementing various filter.

Filters idea

• upper, lower -> natives.
• slugify : escape for Posgres native.

Tasks

• Implementation
• Documentation

[zurikus]

I think that this feature will spread ldap2pg package usability.
Plus for all this filters from me:

a) upper, lower
b) slugify('some string') // some-string
c) // if you prefer something other than '-' as separator
slugify('some string', '_') // some_string

How could be multiple filters applied at once?
d) lower(slugify('Some String', '_')) // some_string

[zurikus]

At this moment I don't think, that LDAP values filtering will be usable, as we need to authenticate user later and apply a reverse filter on applied previously, but it is error-prone.
It is better to rely on LDAP completely.

[bersace]

@zurikus

How could be multiple filters applied at once?

Filters are chainable: {cn.filter0().filter1()}. I could even manage to not require () with a bit of magic.

Let's wait for some more feedback on this. Maybe a cookbook section on this subject would help.

[bersace]

For now, there is a bug. ldap2pg doesn't properly infer LDAP attributes from {cn.lower()}

[bersace]

For the record, this require Postgres to be able to find back the right value to query LDAP directory for password. This is not likely to be easy. So, the better is not to modify LDAP values in ldap2pg, but rather have a preprocessed attribute directly in LDAP directory.

Let's keep this open for a few weeks before closing it.

[bersace]

I'm closing, post processing in ldap2pg what can't be done in pg_hba is useless. Thanks for the issue.