AW: [Openinteract-help] SPOPS::LDAP bug with MAY attributes

[Kutter M. <mar...@er...>]

Hi Cris !

LDAP schema...
...now, let's explain.

LDAP schemata are similar to table definitions in RDBMS, but more =
flexible
(I think the Postgres object-relational approach is somewhat more =
similar to
LDAP than a classic RDBMS like mysql or oracle).

LDAP schemata are something like (yup really) perl classes without =
methods.
They may be combined (i.e. one object may have more than one object =
class),
but (at least if the LDAP server applies "strict" schema checking) =
there
must be exactly one "structural" (...hmm, let's say that's "concrete") =
class
in one object (there can be as many "auxiliary" classes as you like.
"Abstract" classes just serve as parents for structural and auxiliary
classes and may be added to a object definition automatically - this =
depends
on the LDAP server implementation).=20

Retrieving LDAP schemata from an LDAP server is not really difficult - =
but
as you have to retrieve _all_ schemata an object belongs to (e.g. all =
its
object classes) and iterate over the list to find out which attributes =
are
required ("MUST") and which are optional ("MAY") this is a bit more =
work
than just defining the required attributes in the SPOPS configuration.

Moreover, the suggested SPOPS configuration addition does not impose =
any
changes on existing SPOPS systems using LDAP, unless these rely on the =
LDAP
server throwing an exception when an empty value is stored. If the =
proposed
"ldap_required_fields" is empty, SPOPS would just ignore undefined =
values
resp. delete them if they had been set previously.=20

The "skip_undef" switch would check _before_ whether to ignore an =
undefined
SPOPS attribute at all, ignoring it if appropriate.

Maybe for the case mentioned above (relying on LDAP to throw errors on
receiving empty attributes) another configuration switch should be
incorporated (let's say: "ldap_check_fields"). This would mean perfect
compatibility to previous SPOPS versions:=20
If "ldap_check_fields" is not set, "ldap_required_fields" would have no
effect, resulting in the momentary behaviour.

I already got an implementation up for that (currently a patch against
SPOPS-0.85). I will change the "ldap_must_fields" name to
"ldap_required_fields" and add the "ldap_check_fields" configuration =
flag,
if you regard this as useful.

Regards,

Martin Kutter

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Mittwoch, 26. Mai 2004 03:26
An: Kutter Martin
Cc: help Openinteract (E-Mail)
Betreff: Re: [Openinteract-help] SPOPS::LDAP bug with MAY attributes


On May 24, 2004, at 5:11 AM, Kutter Martin wrote:
> There is a little flaw in SPOPS::LDAP when it comes to attributes=20
> which are
> defined as "MAY" in the ldap objectclass definition. These attributes =

> are
> optional, they may be present or not.
>
> When storing a new LDAP object, SPOPS stores all attributes, =
including
> undefined ones (unless these are listed in "skip_undef" - more =
later).
> ...

Hi Martin,

It would be very easy for someone other than me to become the=20
SPOPS::LDAP expert :-) I don't use LDAP any longer and most of the=20
knowledge that I once had has since evaporated.

Anyway, let's see if we can address your items...

> If an optional attribute is stored with an undefined value, this=20
> normally
> results in an LDAP schema error (something like "value not permitted =
by
> syntax").
>
> Adding all optional attributes to "skip_undef" works well for storing =

> new
> objects ("insert" calls): they are simply ignored, thus not included, =

> which
> is exactly what "MAY" means.
>
> But deleting an optional attribute from an already stored object=20
> ("update"
> call) does not work this way: Deleting the attribute means setting it =

> to
> undef in SPOPS - and as undefined values are skipped, the removal of=20
> the
> attribute is not stored in the LDAP directory.
>
> I would suggest the addition of a config parameter=20
> ("ldap_must_fields") as a
> solution.

This would seem to make sense, although 'ldap_required_field' might be=20
a better name.

> The "save_insert" method should regard this parameter in the opposite =

> way of
> skip_undef: All attributes that are mentioned in "ldap_must_fields" =
are
> included in the LDAP::Entry object to save, all other undefined=20
> attributes
> are not.
>
> The "save_update" method should check for undefined attributes and=20
> delete
> them from the Net::LDAP object (unless they are mentioned in=20
> skip_undef).
>
> This solution would remove the need to "abuse" skip_undef for =
optional=20
> ldap
> attributes (and the side effect of impossible removal).

Sure, this seems to make sense and is easier to debug as well.

Like to take a shot at coding this up?

> Another possible solution would be the retrieval of LDAP schemata for =

> SPOPS
> objects and automatically not setting resp. deleting "MAY" attributes =

> if
> these are empty - but this should be harder to implement.

I'll take your word for it. Are LDAP schemas as standard as database=20
schemas?

Thanks!

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988