[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