RE: 'userpassword' handling in backend

["Kervin L. Pierre" <kervin@blueprint-tech.com>]

makes sense now.

I guess the consensus is to have add behave like modify, and push the
key/value pairs onto the perl stack as modify does.  This does make things
simpler on the perl module.
I'll try do this the first chance I get.

--Kervin


> The userPassword attribute is defined to have a binary syntax. The
> entry2str function LDIF-encodes values, and in LDIF, binary attributes
> get base64 encoded.
> The back-perl modify code assumes all of its attributes are ordinary
> strings. It probably should be doing a syntax check of some kind. I
> guess this is a bug in the modify code; attempting to modify any binary
> attribute will cause problems.
> (e.g., jpegphoto, usercertificate...)
>
> My personal feeling here is that treating everything as binary would be
> preferable to using LDIF, but it's not clear which side would be harder
> to fix,
> add vs modify.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>
>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kervin L.
>> Pierre Sent: Tuesday, May 28, 2002 1:12 PM
>> To: openldap-devel@OpenLDAP.org
>> Subject: 'userpassword' handling in backend
>>
>>
>> hello,
>>
>> the way the userpassword is handled seems to inconsistent.  If an
>> entry is added with the 'userpassword' attribute then the value is
>> encoded in base64 before being passed to back-perl. This is done in
>> entry2str() function.  If the 'userpassword' is being set with an
>> ldapmodify, then the value is not encoded before being passed to the
>> backend.
>> My question is, what are the benefits of base64 encoding the
>> userpassword attribute?  If it is done with the ldapadd, shouldn't be
>> done with the ldapmod as well?
>>
>> --Kervin