[Date Prev][Date Next] [Chronological] [Thread] [Top]

about DN rewrite/remap overlay



Every now and then I give a look at this overlay, and realize there are
more and more design issues, it's not just a matter of extracting the
related code from back-ldap.

If, in rewriting a DN, the RDN happens to be rewritten as well, I guess
the distinguished values and, in case of mapping, the naming attributes
need to be rewritten as well.  This implies:

- rewrite the real into the virtual NC (already there)
- pretty/normalize the real DN
- pretty/normalize the virtual NC (pretty already there)
- compare the normalized RDNs (easy: in normalized form,
  look for ','; if an, the DN must be rooted at ""); if they differ:
  - parse both normalized RDNs
  - parse both pretty RDNs
  - remove the real AVAs from the virtual AVAs
  - remove from the entry what remains of the real RDN AVAs
  - add to the entry what remains of the virtual RDN AVAs,
    if they were in the search attribute list or if "*"
    was requested.

The reverse should be applied to add, modify and modrdn operations.  This
is mucking with entry values, but I think it is a required mucking,
otherwise the entries wouldn't be consistent.  In usual operations, this
should never occur, because the typical use of DN rewrite is to map real
to virtual naming contexts; however, people might want to use it to
rewrite DNs, e.g. "uid=<uid>" style into "cn=<givenName> <sn>" style or
so; the underlying rewrite engine is capable of doing it, so we should
ensure the resulting entries comply with the checks.

Comments?

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497