Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-513

Do delete before add when modifying attribute values

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4.0
    • Fix Version/s: 1.5.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None

      Description

      When connecting to Novell eDirectory and modifying the schema an "Attribute Or Value Exists" error occurs. This is due to the modification performing an add before the delete and eDirectory (wrongly) complains that the same OID has been used more than once before realising that the old value should be deleted. Note that this is a problem with eDirectory but it would be useful if Studio asked for the delete to be performed before the add when modifying an attribute value which eDirectory is OK with.

      An example of the LDIF in the modifications logs view for an operation that fails is:

      dn: cn=schema
      changetype: modify
      add: objectClasses
      objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' [...new value...]
      -
      delete: objectClasses
      objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' [...old value...]
      -

      It also seems that modifying the schema on ApacheDS has the same issue.

        Activity

        Hide
        Leo Bergolth added a comment -

        I am currently facing similar problems when trying to modify openldap's
        runtime configuration: Many attributes like olcDbConfig don't have
        equality matching rules, therefore delete/add modifications won't work.

        So at least offering an option to do replace modifications instead of
        add/delete even on multi-valued attributes would be really useful.

        Show
        Leo Bergolth added a comment - I am currently facing similar problems when trying to modify openldap's runtime configuration: Many attributes like olcDbConfig don't have equality matching rules, therefore delete/add modifications won't work. So at least offering an option to do replace modifications instead of add/delete even on multi-valued attributes would be really useful.
        Hide
        Stefan Seelmann added a comment -

        The current behaviour is as follows:

        • modification of an existing value of an single-valued attribute: replace mod
        • modification of an existing value of an multi-valued attribute: add+delete mod
        • additon of a value: add mod
        • deletion of a value: delete mod

        So currently the schema isn't considered for attribute modifications.

        For servers that provide a good schema it would be best to consider the schema:

        • if an equality matching rule exists for the attribute:
        • modification of an existing value (mv or sv): add+delete mod or delete+add mod
        • additon of a value: add mod
        • deletion of a value: delete mod
        • if no equality matching rule exists for the attribute: always use replace mod

        For servers that provide a less good schema we should allow a manual configuration.

        So I would suggest that we add the following configuration parameters for each connection (not to the global preferences as it is depends on the server):

        • Checkbox: "Use schema to determine operations for attribute modification" (with the description above in the tooltip)
          This checkbox is checked by default. If unchecked the following settings become enabled:
        • modification of an existing value of an single-valued attribute: [add+delete mod|delete+add mod|replace mod]
        • modification of an existing value of an multi-valued attribute: [add+delete mod|delete+add mod|replace mod]
        • additon of a value: selectbox: [add mod|replace mod]
        • deletion of a value: [delete mod|replace mod]
          Note: [value1|value2|value3] are drop-down boxes with one selectable value.

        I hope that meets all your requrirements.

        PS: Sure, it would be possible to always use replace. However when editing groups with tons of members then for each modification all members would be transfered over the wire. So I would suggest to keep the add and delete modification. But feel free to convince me.

        PPS: The ultimate solution would be to define an extension point and to add one plugin for each server type the controls the modification operation. But then we would have one driver for each directory server implementation like it is the case for databases. I thought LDAP is an implementation independent protocol...

        Show
        Stefan Seelmann added a comment - The current behaviour is as follows: modification of an existing value of an single-valued attribute: replace mod modification of an existing value of an multi-valued attribute: add+delete mod additon of a value: add mod deletion of a value: delete mod So currently the schema isn't considered for attribute modifications. For servers that provide a good schema it would be best to consider the schema: if an equality matching rule exists for the attribute: modification of an existing value (mv or sv): add+delete mod or delete+add mod additon of a value: add mod deletion of a value: delete mod if no equality matching rule exists for the attribute: always use replace mod For servers that provide a less good schema we should allow a manual configuration. So I would suggest that we add the following configuration parameters for each connection (not to the global preferences as it is depends on the server): Checkbox: "Use schema to determine operations for attribute modification" (with the description above in the tooltip) This checkbox is checked by default. If unchecked the following settings become enabled: modification of an existing value of an single-valued attribute: [add+delete mod|delete+add mod|replace mod] modification of an existing value of an multi-valued attribute: [add+delete mod|delete+add mod|replace mod] additon of a value: selectbox: [add mod|replace mod] deletion of a value: [delete mod|replace mod] Note: [value1|value2|value3] are drop-down boxes with one selectable value. I hope that meets all your requrirements. PS: Sure, it would be possible to always use replace. However when editing groups with tons of members then for each modification all members would be transfered over the wire. So I would suggest to keep the add and delete modification. But feel free to convince me. PPS: The ultimate solution would be to define an extension point and to add one plugin for each server type the controls the modification operation. But then we would have one driver for each directory server implementation like it is the case for databases. I thought LDAP is an implementation independent protocol...
        Hide
        Leo Bergolth added a comment -

        I think considering the schema with a possible per-server configuration override is a very good solution.

        Show
        Leo Bergolth added a comment - I think considering the schema with a possible per-server configuration override is a very good solution.
        Hide
        Quanah Gibson-Mount added a comment -

        Stefan,

        I think the problem is more that some people choose to hide their schema from being read out of the subschema entry, which is a perfectly valid thing to do. So any well written LDAP client needs to be able to work with the fact that the schema may or may not be browsable. There is even some security suite out there that "warns" people that exposing the subschema entry is a security risk. Not that I agree with it.

        Show
        Quanah Gibson-Mount added a comment - Stefan, I think the problem is more that some people choose to hide their schema from being read out of the subschema entry, which is a perfectly valid thing to do. So any well written LDAP client needs to be able to work with the fact that the schema may or may not be browsable. There is even some security suite out there that "warns" people that exposing the subschema entry is a security risk. Not that I agree with it.
        Hide
        Stefan Seelmann added a comment -

        The connection wizard and properties now contain a fourth tab called 'Editor Option'. The modify operation done in entry editors can be configured there. For attributes with equality matching rules (EMR) and for attributes without EMR the 'modify mode' could be selected, there are three options:

        • Optimized: uses add/del, but uses replace if count of replace operation is less (default)
        • Replace: always uses replace operations
        • Add/Delete: always uses add and delete operations

        Additonally, when using add/delete the modify order is configurable: delete first or add first.

        @Martin: The default modification order is 'Delete first' which should solve your problem.
        BTW: I don't think that this is an eDirectory problem, sorry if I claimed that in earlier mails. The attribute objectClasses uses objectIdentifierFirstComponentMatch, so only the OID is used to check if two values are equal. Even if the add would work, which value should be deleted by the delete operation? Both values would match. So IMO the only valid modification order is delete first, then add.

        @Leo: In your case just select REPLACE for attributes w/o EMR.

        I tested with ApacheDS, OpenLDAP, SunDS, OpenDS, FedoraDS, eDirectory and Active Directory.

        To sum up: this is a field where various LDAP server are implemented very differently:

        • OpenLDAP is very strict, attributes w/o EMR must be edited using replace operation
        • ApacheDS and OpenDS allow to use add and delete operations for attributes without EMR
        • In FedoryDS many standard attribute types (cn, teleponeNumber, etc.) don't define an EMR, however add/delete operations work
        • Active Directory and eDirectory don't expose any EMR at all, however add/delete operations work
        Show
        Stefan Seelmann added a comment - The connection wizard and properties now contain a fourth tab called 'Editor Option'. The modify operation done in entry editors can be configured there. For attributes with equality matching rules (EMR) and for attributes without EMR the 'modify mode' could be selected, there are three options: Optimized: uses add/del, but uses replace if count of replace operation is less (default) Replace: always uses replace operations Add/Delete: always uses add and delete operations Additonally, when using add/delete the modify order is configurable: delete first or add first. @Martin: The default modification order is 'Delete first' which should solve your problem. BTW: I don't think that this is an eDirectory problem, sorry if I claimed that in earlier mails. The attribute objectClasses uses objectIdentifierFirstComponentMatch, so only the OID is used to check if two values are equal. Even if the add would work, which value should be deleted by the delete operation? Both values would match. So IMO the only valid modification order is delete first, then add. @Leo: In your case just select REPLACE for attributes w/o EMR. I tested with ApacheDS, OpenLDAP, SunDS, OpenDS, FedoraDS, eDirectory and Active Directory. To sum up: this is a field where various LDAP server are implemented very differently: OpenLDAP is very strict, attributes w/o EMR must be edited using replace operation ApacheDS and OpenDS allow to use add and delete operations for attributes without EMR In FedoryDS many standard attribute types (cn, teleponeNumber, etc.) don't define an EMR, however add/delete operations work Active Directory and eDirectory don't expose any EMR at all, however add/delete operations work
        Hide
        Stefan Seelmann added a comment -

        @Quanah: Thanks for the pointer. I also tested with hidden schema. In that case Studio falls back to a built-in default schema (that is derived from OpenLDAP and contains all the standard schema objects). However I wonder if this makes really sense. When the server really uses standard schema this approach works fine. However if there are custom schema elements Studio can't guess which attributes are allowed or required and pops up wrong warnings. So my idea is to remove this default schema and to disable all the schema checks if no schema is present. Thanks again.

        Show
        Stefan Seelmann added a comment - @Quanah: Thanks for the pointer. I also tested with hidden schema. In that case Studio falls back to a built-in default schema (that is derived from OpenLDAP and contains all the standard schema objects). However I wonder if this makes really sense. When the server really uses standard schema this approach works fine. However if there are custom schema elements Studio can't guess which attributes are allowed or required and pops up wrong warnings. So my idea is to remove this default schema and to disable all the schema checks if no schema is present. Thanks again.
        Hide
        Stefan Seelmann added a comment -
        Show
        Stefan Seelmann added a comment - Fixed in trunk: http://svn.apache.org/viewvc?rev=824365&view=rev
        Hide
        Martin Alderson added a comment -

        Stefan: On the mailing list you convinced me it was an eDirectory problem by quoting RFC4511, section 4.6:

        ------------------------------------------------------------------------
        ........ as a single atomic operation. While individual
        modifications may violate certain aspects of the directory schema
        (such as the object class definition and Directory Information Tree
        (DIT) content rule), the resulting entry after the entire list of
        modifications is performed MUST conform to the requirements of the
        directory model and controlling schema [RFC4512].
        ------------------------------------------------------------------------

        To me, this sounds like the order of add and delete operations shouldn't matter as far as schema validation goes. I guess you are right about the delete operation though - it wouldn't know which value to delete. That could lead to the object class you add being deleted immediately!

        The solution you've implemented for studio sounds good, thanks.

        Show
        Martin Alderson added a comment - Stefan: On the mailing list you convinced me it was an eDirectory problem by quoting RFC4511, section 4.6: ------------------------------------------------------------------------ ........ as a single atomic operation. While individual modifications may violate certain aspects of the directory schema (such as the object class definition and Directory Information Tree (DIT) content rule), the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory model and controlling schema [RFC4512] . ------------------------------------------------------------------------ To me, this sounds like the order of add and delete operations shouldn't matter as far as schema validation goes. I guess you are right about the delete operation though - it wouldn't know which value to delete. That could lead to the object class you add being deleted immediately! The solution you've implemented for studio sounds good, thanks.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Apache Directory Studio version 1.5.0 has been released.

        Show
        Pierre-Arnaud Marcelot added a comment - Apache Directory Studio version 1.5.0 has been released.

          People

          • Assignee:
            Stefan Seelmann
            Reporter:
            Martin Alderson
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development