[Date Prev][Date Next]
RE: 'userpassword' handling in backend
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.
> 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
>> 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
>> 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?