Re: [Fwd: sUffixAlias]

[Pierangelo Masarati <pmasarati@bci.it>]

"Kurt D. Zeilenga" wrote:

> I have a couple of quick comments:
>
> Values of user provided attributes should not be modified by
> the server on input or output.  As DNs are derived, in general,
> from user provided attributes, they should not be modified as
> well.  This is true for the master, a slave, or any proxy.

Yes, that sounds correct for user-provided data, but I'm thinking
about the SUFFIX of the data, i.e. the subfloor provided by the
system to host user data. As an example, if I plan to make a hidden
portion of my server available only thru dn rewriting, and someone
searches for an entry that contains a "owner" attribute, I expect
its value to reflect the dn massaging. I'm not going to alter user data
at all!

>
> suffixAlias was meant as an aliasing mechanism.  It's handling
> should be consistent with other forms of aliasing.

I had hard times in figuring out how it works by reading the code
and a few mails about the topic. What I realized (from the CVS
messages) is that this code kept jumping in and out for a while ;)

>
> Now I believe there could be some interesting work done to
> support virtual views.  A virtual view backend could be
> viewed as one as providing some rewriting capabilities.

I was also thinking about some mod_rewrite-like stuff,
i.e. regexp based, but what could it apply to? I'm not sure we
want to rewrite any attribues; it is likely we need to rewrite
the path to the entries at most.

>
> However, I do believe it inappropriate to place rewriting
> capabilities in the frontend.

I intended it as as a possible approach, as doing the work once
for any future backend would save efforts if such feature
happens to be useful. Of course, the back-ldap would benefit
most of some dn rewrite capabilities.

Think of a back-ldap that maps one suffix (or more) to a set
of servers with different suffix, maybe with different schemas,
organization, depth and so. Each operation (not dn-based) would
require to propagate to each server, and results to be sent back,
possibly rewritten in the suffix of the dn and of the attributes
with dn syntax, if rewriting rules apply.

I know LDAP was meant to distribute information, but
companies tend to hide information rather than to make it
available. This could help in allowing some reasonable entry
points in otherwise hidden directory servers.

Anyway, apart from the considerations about rewriting the
returning attributes, which can be delayed, I'd like to start
doing something; the first thing to do seems to me to decide
if and how this project could be interesting for the community,
and to what extent it's recommendable that I put my hands
in the front-end stuff. I realize you discourage this approach,
and I'm also positive the most appropriate point to work about
is the back-ldap. Any suggestions are welcome.

Regards, Pierangelo


--
Pierangelo Masarati <ando@sys-net.it>
SysNet s.n.c.