[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: modifying multi-valued entry with no values
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For the record.
I don't know what got in me last weekend, but I was adding wrong assumptions
to configuration mistakes. For the archives:
OpenLDAP 2.1.22
If an attribute is tagged as MUST in the schema, the attribute must be there.
Wheter it may contain and empty value depends on the SYNTAX for that
attribute.
DirectoryString MAY NOT be empty; OctetString MAY be empty (Kurt Zeilenga).
As far as I can see, IA5String MAY NOT be empty.
I haven't found a document that describes the syntaxes in BNF format.
http://www.faqs.org/rfcs/rfc1487.html seems to define IA5String as
OctetString. If anyone has a good link for all these SYNTAXes, please reply
to this message.
If an attribute is defined as MAY in the schema, the attibute may or may not
be there. If it is there, it MAY or MAY NOT be empty, depending in it's
SYNTAX.
PHP 4.3.1
In http://www.php.net/manual/en/function.ldap-modify.php, the user comment
about ldap_modify() (repeated below) seems to be FALSE. I wish someone at
php.net would remove that comment or edit it.
It seems that ldap_modify() will take an array of attributes to modify.
For multivalued attributes, passing an empty array, wil DELETE the attribute,
regardless of it's previous value(s), and regardless if the attribute was
there before the modify.
If the multivalued attribute is defined as MAY, this will work. If the
attribute is defined as MUST, OpenLDAP will generate the error: 'LDAP error
65: Object class violation'
If an attribute's SYNTAX defines that it MAY NOT be empty, trying to add or
modify the attribute with an empty value will genereate the error: 'LDAP
error 21: Invalid syntax'.
Also, in the logfile, if set with sufficient debuglevel, the string
value #0 invalid per syntax
will be present. (Googling for this string gives some questions about this,
but hardly any answers, so I hope this mail will help someone).
Trying to pass an empty array to ldap_add() for a any attribute (multi or
single valued) will result in the error 'LDAP error 2: Protocol error',
regardless if the attribute is defined as MUST or MAY.
Note that this differs form passing and array with elements that have no
value. In the latter case, it depends on the SYNTAX for that attribute if
that is allowed.
If the attribute is single-valued, passing an array with one element, WILL
change the value of the attribute. In the user comments on php.net it is
suggested that if you want to modify a single valued attribute, you must pass
a string, not an array with one element. My experience is that an array with
a single element will work just as well.
- -----
Sorry if this is offtopic for this list - I just wanted to archive these
findings.
_Ace
> Hi,
>
> From http://www.php.net/ldap_modify :
>
> 'The behaviour of OpenLDAP from 1.x to 2.x changed; in 1.x, when you passed
> ldap_modify the array, if the value was empty that attribute would be
> deleted. In 2.x, you get an "Invalid Syntax" error and the modify fails.
>
> This requires the ldap_mod_del function; unfortunately, that operation
> requires the attribute to be deleted have it's *old* value specified -- as
> you can imagine, if you're taking input from a CGI form, the attribute to
> be deleted's value is now missing (i.e., the user blanked out that textbox
> in the form and clicked Submit).
>
> So, you're in a bit of a conundrum -- you want to delete "empty" form
> values, but you need their old value to delete them.'
>
> Is this true ?
> If yes, it poses some kind of a problem for me. I am trying to make a
> webinterface to manage some ldap entries, but I would really like to do
> modifcations 'atomically'.
>
> That is, I want one call to ldap_modify to modify all attributes that need
> modification.
>
> This works fine for instance with this:
>
> OLD VALUES:
> mailalternateaddress: usera@example.com
> mailalternateaddress: auser@example.com
> mailalternateaddress: postmaster@example.com
>
> NEW VALUES:
> mailalternateaddress: usera@example.com
> mailalternateaddress: somethingelse@example.com
>
> afer ldap_modify, the entry reflects the new values, i.e. al old values
> have been deleted and the new ones inserted. (Don't know if it woks that
> way internally, but that's the result).
>
> Now, the problem arises when trying to modify the entry by deleting all the
> values:
>
> OLD VALUES:
> mailalternateaddress: usera@example.com
> mailalternateaddress: auser@example.com
> mailalternateaddress: postmaster@example.com
>
> NEW VALUES:
> nothing, obviously.
>
> Using ldap_modify, this raises some error.
> Now of course, if this was the only attribute I needed to modify, that
> would't be a big problem. But consider:
>
>
> OLD VALUES:
> mail: alice@example.com
> mailalternateaddress: usera@example.com
> mailalternateaddress: auser@example.com
> mailalternateaddress: postmaster@example.com
>
> NEW VALUES:
>
> mail: bob@example.com
>
> i.e. we want to change the mail attribute, and get rid of all the
> mailalternateaddress attributes.
>
> It seems that TWO calls to ldap_something are needed:
> one to modify 'mail'
> one to 'delete' mailalternateaddress.
>
> Of course, this enables all sorts of race conditions, and generally
> programming awkwardness.
>
> What was the reason to change this behaviour, and is there a way to
> circumvent the non-atomicness of modifying (empty) attributes ?
>
> Sincerely,
>
> ace
>
>
> website: http://www.suares.nl * http://www.qwikzite.nl
- --
Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQE/1HC3y7boE8xtIjURAuxdAJ9q6ip5OsBY3qBFcZVZ5Ku7DN5MYQCgh/RY
waBlVETegadTogKZ6jSchzU=
=Rvtp
-----END PGP SIGNATURE-----