Re: [Fwd: sUffixAlias]

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:04 PM 12/5/00 +0100, Pierangelo Masarati wrote:
>"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!

'owner' is a user attribute.


>>
>> 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 ;)

suffixAliasing code, in many ways, is not consistent with other
forms of aliasing.  My point is that it SHOULD be.

>> 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.

I was under the impression that you wanted to rewrite values
of user attributes, specifically those which hold DNs.


>>
>> 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.