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

[Chris W. <ch...@cw...>]

On May 24, 2004, at 5:11 AM, Kutter Martin wrote:
> There is a little flaw in SPOPS::LDAP when it comes to attributes 
> 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 
SPOPS::LDAP expert :-) I don't use LDAP any longer and most of the 
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 
> 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 
> ("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 
> the
> attribute is not stored in the LDAP directory.
>
> I would suggest the addition of a config parameter 
> ("ldap_must_fields") as a
> solution.

This would seem to make sense, although 'ldap_required_field' might be 
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 
> attributes
> are not.
>
> The "save_update" method should check for undefined attributes and 
> delete
> them from the Net::LDAP object (unless they are mentioned in 
> skip_undef).
>
> This solution would remove the need to "abuse" skip_undef for optional 
> 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 
schemas?

Thanks!

Chris

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