Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0-M3 (2.0.0.v20120224)
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      It seems that the eDirectory networkAddress attribute is hard for Studio to read.
      There are several more attributes that use the same syntax (2.16.840.1.113719.1.1.5.1.12)
      When looking at a ncpServer object (objectClass=ncpServer) it has several values in that attribute.
      Studio displays them pretty well, they look like this:

      13#l d a p : / / 1 7 2 . 1 6 . 2 4 2 . 7 4 : 6 3 6
      Notice the space between each character.
      I believe its a \u0000 but I'm 100% sure.
      Anyway selecting a value and pressing CTRL+C gives me:
      13#l
      I.e. only the first four characters up to the first "space".
      If I double click the value to edit it then Studio displays 13#l in the editor field.
      If you by accident click anywhere and you don't press ESC then the value will be changed to 13#l
      It would be nice if doubleclicking the attribute value wouldn't cause Studio to change the value.

        Issue Links

          Activity

          Hide
          Pierre-Arnaud Marcelot added a comment -

          "\u0000" is the null character in unicode and it seems Studio doesn't like it very much...

          Could you export the entry as LDIF (probably not using Studio, since it seems to do something wrong with the value) and attach it here?

          Thanks.

          Show
          Pierre-Arnaud Marcelot added a comment - "\u0000" is the null character in unicode and it seems Studio doesn't like it very much... Could you export the entry as LDIF (probably not using Studio, since it seems to do something wrong with the value) and attach it here? Thanks.
          Hide
          Aleks M added a comment -

          Here it is.

          networkAddress:: OSMCDKwQ8ko=
          networkAddress:: OCMCDKwQ8ko=
          networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO
          AAwADIAOAAvAHAAbwByAHQAYQBsAAAA
          networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO
          gA4ADAAMwAwAC8AcABvAHIAdABhAGwAAAA=
          networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO
          AAwADIAOAAvAG4AZABzAAAA
          networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO
          gA4ADAAMwAwAC8AbgBkAHMAAAA=
          networkAddress:: MTMjbABkAGEAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAM
          wA4ADkAAAA=
          networkAddress:: MTMjbABkAGEAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO
          gA2ADMANgAAAA==
          networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO
          AAwADIAOAAvAHMAbwBhAHAAAAA=
          networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO
          gA4ADAAMwAwAC8AcwBvAGEAcAAAAA==

          Show
          Aleks M added a comment - Here it is. networkAddress:: OSMCDKwQ8ko= networkAddress:: OCMCDKwQ8ko= networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO AAwADIAOAAvAHAAbwByAHQAYQBsAAAA networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO gA4ADAAMwAwAC8AcABvAHIAdABhAGwAAAA= networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO AAwADIAOAAvAG4AZABzAAAA networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO gA4ADAAMwAwAC8AbgBkAHMAAAA= networkAddress:: MTMjbABkAGEAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAM wA4ADkAAAA= networkAddress:: MTMjbABkAGEAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO gA2ADMANgAAAA== networkAddress:: MTMjaAB0AHQAcAA6AC8ALwAxADcAMgAuADEANgAuADIANAAyAC4ANwA0ADoAO AAwADIAOAAvAHMAbwBhAHAAAAA= networkAddress:: MTMjaAB0AHQAcABzADoALwAvADEANwAyAC4AMQA2AC4AMgA0ADIALgA3ADQAO gA4ADAAMwAwAC8AcwBvAGEAcAAAAA==
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Thanks.

          Except the two first ones, every other Base64 value is correctly decoded and correspond to a valid address (prefexed with "13#").
          Here's the last value for example:
          13#https://172.16.242.74:8030/soap

          But I don't see any space in them, which is pretty weird

          As I don't have any eDirectory instance here to test on, it's make it difficult to go further on debugging...

          Show
          Pierre-Arnaud Marcelot added a comment - Thanks. Except the two first ones, every other Base64 value is correctly decoded and correspond to a valid address (prefexed with "13#"). Here's the last value for example: 13# https://172.16.242.74:8030/soap But I don't see any space in them, which is pretty weird As I don't have any eDirectory instance here to test on, it's make it difficult to go further on debugging...
          Hide
          Aleks M added a comment -

          I can upload a VMware image with eDirectory installed somewhere if you want to test it?

          Show
          Aleks M added a comment - I can upload a VMware image with eDirectory installed somewhere if you want to test it?
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Thanks to Aleks M., who provided me a VM to reproduce the issue, we have been able to make progress on this issue.

          The issue is present on Windows and Linux, BUT is not present on OS X. Go figure why....

          If we open one of the values of this attribute in the Hex Editor, we get the following:
          31 33 23 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 13#h.t.t .p.:././
          00 31 00 39 00 32 00 2e 00 31 00 36 00 38 00 2e .1.9.2.. .1.6.8..
          00 30 00 2e 00 31 00 34 00 3a 00 38 00 30 00 32 .0...1.4 .:.8.0.2
          00 38 00 2f 00 6e 00 64 00 73 00 00 00 .8./.n.d .s...

          We can notice that after the start of an URL (this only occurs after the # character), each character of the URL is followed by a "00" hexadecimal value and that we also have three of them at the end.

          The 'networkAddress' attribute has a '2.16.840.1.113719.1.1.5.1.12' syntax OID.
          This page [1] explains that "The address itself is stored as a binary string. This string is the literal value of the address. To display it as a hexadecimal value, you must convert each 4-bit nibble to the correct character (0,1,2,3,...F)."

          So, the URL is actually a binary string value, hence the difficulties we are getting while trying to display it as simple string.

          I'm still unsure whether we can really easily fix that issue without requiring a specific value editor for this kind of syntax.

          [1] - http://www.novell.com/documentation/developer//ndslib/schm_enu/?page=/documentation/developer//ndslib/schm_enu/data/sdk5624.html

          Show
          Pierre-Arnaud Marcelot added a comment - Thanks to Aleks M., who provided me a VM to reproduce the issue, we have been able to make progress on this issue. The issue is present on Windows and Linux, BUT is not present on OS X. Go figure why.... If we open one of the values of this attribute in the Hex Editor, we get the following: 31 33 23 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 13#h.t.t .p.:././ 00 31 00 39 00 32 00 2e 00 31 00 36 00 38 00 2e .1.9.2.. .1.6.8.. 00 30 00 2e 00 31 00 34 00 3a 00 38 00 30 00 32 .0...1.4 .:.8.0.2 00 38 00 2f 00 6e 00 64 00 73 00 00 00 .8./.n.d .s... We can notice that after the start of an URL (this only occurs after the # character), each character of the URL is followed by a "00" hexadecimal value and that we also have three of them at the end. The 'networkAddress' attribute has a '2.16.840.1.113719.1.1.5.1.12' syntax OID. This page [1] explains that "The address itself is stored as a binary string. This string is the literal value of the address. To display it as a hexadecimal value, you must convert each 4-bit nibble to the correct character (0,1,2,3,...F)." So, the URL is actually a binary string value, hence the difficulties we are getting while trying to display it as simple string. I'm still unsure whether we can really easily fix that issue without requiring a specific value editor for this kind of syntax. [1] - http://www.novell.com/documentation/developer//ndslib/schm_enu/?page=/documentation/developer//ndslib/schm_enu/data/sdk5624.html

            People

            • Assignee:
              Unassigned
              Reporter:
              Aleks M
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development