[Date Prev][Date Next]
Re: [Fwd: sUffixAlias]
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
'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.
>Pierangelo Masarati <email@example.com>