Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-468

The LDIF parser does not correctly parse changes

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3.0
    • Fix Version/s: 1.4.0
    • Component/s: studio-ldifeditor
    • Labels:
      None

      Description

      Trying to parse such a LDIF :

      1. principal: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
      2. timestamp: 1235905921781
      3. revision: 1235905920724
        dn: 2.5.4.3=the person,2.5.4.11=system
        changeType: modify
        add: objectclass
        objectclass: organizationalPerson
        objectclass: inetOrgPerson
        -

      you get an error message, as the last '-' is considered as a wrong token

        Activity

        Hide
        Stefan Seelmann added a comment -

        The problem is that the 'T' in changetype is uppercase. This causes that the LDIF isn't recognized as change record. Should the keyword (dn, changtype, modify, add, delete, moddn, etc) be case insensitive?

        Show
        Stefan Seelmann added a comment - The problem is that the 'T' in changetype is uppercase. This causes that the LDIF isn't recognized as change record. Should the keyword (dn, changtype, modify, add, delete, moddn, etc) be case insensitive?
        Hide
        Emmanuel Lecharny added a comment -

        Correct ! Then we have two ways to deal with the problem :

        • accept upper cases for chageType or other constants
        • or generate an error on the right position

        I would pick option #1

        Show
        Emmanuel Lecharny added a comment - Correct ! Then we have two ways to deal with the problem : accept upper cases for chageType or other constants or generate an error on the right position I would pick option #1
        Hide
        Stefan Seelmann added a comment -

        Or a google-like warning "Did you mean: changetype?" as yellow marker.

        Show
        Stefan Seelmann added a comment - Or a google-like warning "Did you mean: changetype?" as yellow marker.
        Hide
        Emmanuel Lecharny added a comment -

        We also have problem with the moddn operation : it's expecting the newRDN, deleteOldRdn and newSuperior in this order.

        Show
        Emmanuel Lecharny added a comment - We also have problem with the moddn operation : it's expecting the newRDN, deleteOldRdn and newSuperior in this order.
        Hide
        Emmanuel Lecharny added a comment -

        I also have a pb with such an entry :

        1. principal: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
        2. timestamp: 1235922630304
        3. revision: 1235922623664
          dn: 2.5.4.3=tori amos,2.5.4.11=system
          changetype: modify

        I don't know what would this change mean, but it's legal from the LDIF grammar POV.

        Show
        Emmanuel Lecharny added a comment - I also have a pb with such an entry : principal: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system timestamp: 1235922630304 revision: 1235922623664 dn: 2.5.4.3=tori amos,2.5.4.11=system changetype: modify I don't know what would this change mean, but it's legal from the LDIF grammar POV.
        Hide
        Stefan Seelmann added a comment -

        Yes, according to RFC 2849. Maybe too strict. Should we allow any order?

        Show
        Stefan Seelmann added a comment - Yes, according to RFC 2849. Maybe too strict. Should we allow any order?
        Hide
        Stefan Seelmann added a comment -

        Is it possible to send an empty modification to the server? What would the server do? Just update the modifyTimestamp, like a touch on unix?

        Show
        Stefan Seelmann added a comment - Is it possible to send an empty modification to the server? What would the server do? Just update the modifyTimestamp, like a touch on unix?
        Hide
        Emmanuel Lecharny added a comment -

        Rearding the order, we may be less strict.

        The empty modification should be accepted. The server won't do anything. This is a direct consequence of what RFC 4511 says about Modify operation :

        "A replace with no value will delete the entire attribute if it exists, and it is ignored if the attribute does not exist."

        When the server received a ModifyRequest with a replace without values for a non existing attribute, the attribute is removed from the request. If we don't have any remaining attribute, the server does nothing.

        A very special corner case, IMO...

        Show
        Emmanuel Lecharny added a comment - Rearding the order, we may be less strict. The empty modification should be accepted. The server won't do anything. This is a direct consequence of what RFC 4511 says about Modify operation : "A replace with no value will delete the entire attribute if it exists, and it is ignored if the attribute does not exist." When the server received a ModifyRequest with a replace without values for a non existing attribute, the attribute is removed from the request. If we don't have any remaining attribute, the server does nothing. A very special corner case, IMO...
        Hide
        Stefan Seelmann added a comment -
        Show
        Stefan Seelmann added a comment - All three issues are fixed: http://svn.apache.org/viewvc?rev=749785&view=rev

          People

          • Assignee:
            Stefan Seelmann
            Reporter:
            Emmanuel Lecharny
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development