Re: forgive the newbie q's! :/

["Pierangelo Masarati" <ando@sys-net.it>]

> Hey there. I was hoping to brick some brains here... so here goes... :)
>
> I'm trying to find a way of carrying "inheritable" (OO-like) code
> snippets attached to ldap entries. "like what??"
>
> ok. here's the idea
>
> writing an ldap overlay. it intercepts results etc. etc. from ldap and
> can OPTIONALLY process a result modifying it (or completely rewriting
> it) based on dynamic data. this of course requires a way of 1. storing
> the procedures to apply to the entry (E.g. perl, python, or whatever),
> and 2. retrieving these stored procedures, being able to modify these
> procedures (remotely via ldap commands) and inspect them, without
> specially configuring the ldap server (E.g. back-perl). the aim is to be
> able to use an ldap client to add, delete and modify the scripts that
> affect the output of an entry and to be able to have a script apply to 1
> particular entry, an entire subtree/class of entries or the entire
> database too (ie every level in the ldap tree). what language the script
> is in is not really relevant at this stage - but just think that it
> could be perl, python, java bytecode, C# bytecode or anything else - as
> long as it can be machine independent and interpreted, it doesn't
> matter.
>
> an example is an entry that has someones age AND date of birth as values
> in the object, but since the age will change over time, you
> auto-calculate the age field BASED on the date of birth information
> before handing it off to the next layer up. another example may be "last
> account payment" field. if the last account payment is greater than 90
> days ago, the account is AUTOMATICALLY locked and the account validity
> filed in the account object returned is set to FALSE automatically by a
> script for all members of the "users" directory - BUT some users are
> special (company employees who don't need to pay, or special customers
> with special deals) so you want a different script that ALWAYS lets the
> account be active for these special account entries (thus the need to be
> able to have a script per-entry than can override a more general
> script).
>
> now that i've given the idea of what i'm trying to achieve, i am a bit
> vexed as to the best way to go about it. sure - i have a test overlay
> working, and i am assuming an overlay is the best method, as it means
> the back-end db is independent of any modifying scripts. but now i need
> a way of storing the scripts. i need to store them in a db accessible by
> at least a "manager" user. i have a few ideas.
>
> 1. a new type in a schema that you can add to inetorgperson/orgperson
> etc. schemas (or make a new schema that inherits from these actually and
> adds 1 field) and this new field contains any script to be run per
> entry. if that field is non-empty, that code is run.
>
> the problem is that the CODE is also returned. is there a way of nicely
> making SOME entries visible and others masked/empty depending on the
> user who is authenticated? (if not i could just add that to the
> subsystem that automatically empties the script var entry if the user is
> not the Manager or on a list of users allowed to see the script)
>
> i could also put this in a parallel database under a different top
> level... but that just seems a little nasty.
>
> so what i'm wondering is:
>
> 1. how far off the planet am i?

a bit

> 2. some signposts pointing back to earth would be useful
> 3. seriously - am i going down the right path or what? :)

it may work.  I have a couple of suggestions.
1) I suggest you make these attributes you add operational;
1.a) they are operational, since they act on values
1.b) you don't need to modify objectClasses, since operational
     attributes apply to any entry
1.c) this way, they are returned only when explicitly required
1.d) you may easily protect them from unintended access by ACLs
2) note that the order of attributes is not guaranteed to be preserved, so
if you intend to allow more than one value for scripting attributes, be
sure you implement a mechanism to sort them when they're used.  A syntax
like "OID SPACE SCRIPT", with the prerequisite of executing them after
ordering by OID would be a possible approach
3) you may also want to add a scoping to your scripts, since you talked
about the possibility to having them run for a subtree
4) you may use manageDSAit to handle entry access without triggering the
scripts execution

>
> i will contribute back patches once this doesn't look so ugly anymore -
> so any help is appreciated. :)

One final comment: what you're trying to do has little to do with a DSA,
it has rather more to do with a client; however, it's reasonable that one
wishes to have special borderline features customizable at will; in my
opinion, this is the added value of overlays (or SLAPI; overlays
essentially are native SLAPIs).

Enjoy!

p.

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




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