Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-365

Can't delete entry with studio 1.1.0. works with 1.0.1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.2.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      Studion 1.1.0 standalone or within an existing eclipse installation. IBM directory server

      Description

      Using studio 1.0.1, I can delete an entry using the principal I usually use.
      With the same connection and studion 1.1.0, it fails telling me Error 50.

      !ENTRY org.apache.directory.studio.connection.core 4 4 2008-07-31 11:15:07.806
      !MESSAGE Error while deleting entry
      !STACK 0
      javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'cn=JLS,ou=appli,ou=frisco,o=INTERNET'
      at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2993)
      at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
      at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
      at com.sun.jndi.ldap.LdapCtx.c_destroySubcontext(LdapCtx.java:826)
      at com.sun.jndi.toolkit.ctx.ComponentContext.p_destroySubcontext(ComponentContext.java:653)
      at com.sun.jndi.toolkit.ctx.PartialCompositeContext.destroySubcontext(PartialCompositeContext.java:336)
      at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper$5.run(JNDIConnectionWrapper.java:717)
      at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.runAndMonitor(JNDIConnectionWrapper.java:1047)
      at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.checkConnectionAndRunAndMonitor(JNDIConnectionWrapper.java:978)
      at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.deleteEntry(JNDIConnectionWrapper.java:757)
      at org.apache.directory.studio.ldapbrowser.core.jobs.DeleteEntriesJob.deleteEntry(DeleteEntriesJob.java:361)
      at org.apache.directory.studio.ldapbrowser.core.jobs.DeleteEntriesJob.optimisticDeleteEntryRecursive(DeleteEntriesJob.java:221)
      at org.apache.directory.studio.ldapbrowser.core.jobs.DeleteEntriesJob.executeNotificationJob(DeleteEntriesJob.java:143)
      at org.apache.directory.studio.ldapbrowser.core.jobs.AbstractNotificationJob.executeAsyncJob(AbstractNotificationJob.java:43)
      at org.apache.directory.studio.ldapbrowser.core.jobs.AbstractEclipseJob.run(AbstractEclipseJob.java:101)
      at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
      !SUBENTRY 1 org.apache.directory.studio.connection.core 4 4 2008-07-31 11:15:07.806
      !MESSAGE [LDAP: error code 50 - Insufficient Access Rights]

      1. 1.0.1
        1 kB
        Dominique Jean-Prost
      2. 1.2.0
        0.4 kB
        Dominique Jean-Prost
      3. delete.ldif
        2 kB
        Dominique Jean-Prost

        Issue Links

          Activity

          Hide
          Pierre-Arnaud Marcelot added a comment -

          Hi Dominique,

          Have you tested with the latest version released (1.2.0 RC1)?

          Thanks,
          Pierre-Arnaud

          Show
          Pierre-Arnaud Marcelot added a comment - Hi Dominique, Have you tested with the latest version released (1.2.0 RC1)? Thanks, Pierre-Arnaud
          Hide
          Dominique Jean-Prost added a comment -

          Just tested with 1.20rc1, both standalone and eclipse version : still have the problem. I really wonder what can happens.

          Show
          Dominique Jean-Prost added a comment - Just tested with 1.20rc1, both standalone and eclipse version : still have the problem. I really wonder what can happens.
          Hide
          Emmanuel Lecharny added a comment -

          That's very strange... As the server is returning a 50 error, it seems that the problem is on the server, not on studio. Now, if you are able to delete the entry with an old version of Studio ...

          You have to know that to be able to delete an entry, some condition mut be fulfilled :

          • the user 'own' the entry
          • or the user has the right to delete the entry (check the ACI on your server)
          • the entry must not have sub-elements

          Can you provide a LDIF dump of this entry, including all the operational attributes ?

          Now, as Studio is based on JNDI to operate. I don't think we have changed a lot the way the delete operation works on Studio since the first version (Stefan, can you confirm ?). A good way to check what is goind on would be to capture some network exchanges with WireShark to see what exactly is sent and received.

          Show
          Emmanuel Lecharny added a comment - That's very strange... As the server is returning a 50 error, it seems that the problem is on the server, not on studio. Now, if you are able to delete the entry with an old version of Studio ... You have to know that to be able to delete an entry, some condition mut be fulfilled : the user 'own' the entry or the user has the right to delete the entry (check the ACI on your server) the entry must not have sub-elements Can you provide a LDIF dump of this entry, including all the operational attributes ? Now, as Studio is based on JNDI to operate. I don't think we have changed a lot the way the delete operation works on Studio since the first version (Stefan, can you confirm ?). A good way to check what is goind on would be to capture some network exchanges with WireShark to see what exactly is sent and received.
          Hide
          Dominique Jean-Prost added a comment -

          Well, I agree with you, this error is brought back by server, so this answer should be the same for everyone. Anyway, here is what I've tested :

          Download of 1.0.1, install it, connect to the server, try to delete an entry (the problem is not specific to one particulary). Delete is ok.
          Uninstall of 1.0.1 (both program files and .apache studio)
          Downlaod of 1.2.0,install it, connect to the server, recreate an entry, try to delete it, delete is ko : error 50.

          As you suggested, I installed wireshark, and captured the network between my host and the server for both the tests. Please find them as an attachement. As I just discovered wireshark, I'm not sure my capture is ok or not. I guess it is.

          Hope this help.

          Show
          Dominique Jean-Prost added a comment - Well, I agree with you, this error is brought back by server, so this answer should be the same for everyone. Anyway, here is what I've tested : Download of 1.0.1, install it, connect to the server, try to delete an entry (the problem is not specific to one particulary). Delete is ok. Uninstall of 1.0.1 (both program files and .apache studio) Downlaod of 1.2.0,install it, connect to the server, recreate an entry, try to delete it, delete is ko : error 50. As you suggested, I installed wireshark, and captured the network between my host and the server for both the tests. Please find them as an attachement. As I just discovered wireshark, I'm not sure my capture is ok or not. I guess it is. Hope this help.
          Hide
          Dominique Jean-Prost added a comment -

          network capture between my host and the server using studio 1.0.1

          Show
          Dominique Jean-Prost added a comment - network capture between my host and the server using studio 1.0.1
          Hide
          Dominique Jean-Prost added a comment -

          network capture between my host and the server using 1.2.0 studio

          Show
          Dominique Jean-Prost added a comment - network capture between my host and the server using 1.2.0 studio
          Hide
          Dominique Jean-Prost added a comment -

          network capture between my host and the server using 1.2.0 studio

          Show
          Dominique Jean-Prost added a comment - network capture between my host and the server using 1.2.0 studio
          Hide
          Dominique Jean-Prost added a comment -

          an example of entry I can delete with 1.0.1 but not with 1.2.0 (nor 1.1.0)

          Show
          Dominique Jean-Prost added a comment - an example of entry I can delete with 1.0.1 but not with 1.2.0 (nor 1.1.0)
          Hide
          Emmanuel Lecharny added a comment -

          Ok, I think I know what's going on.

          The 1.2.0 request contains a Tree Delete control, which only administrators can use, so you get the permission error.
          This has been added in 1.2.0. If the rootDSE contains this control, then the delete request is send with it added. Obviously, when you are not an admin on IDS, you will get a failure ... (http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahycontrols.htm)

          There is no workaround, except than using an older version ...

          A fix would be to modify the Delete selection on the browser to ask if the user want to apply the TreeDelete control or not, plus a preference to set it by default, or not.

          Here are the two decoded PDU :

          1.2.0 :
          -------
          30 67
          02 01 10 : MessageId = 16
          4A 2B : Delete request
          cn=testDelete,ou=appli,ou=frisco,O=INTERNET
          A0 35 : Controls
          30 18
          04 16
          1.2.840.113556.1.4.805 : Tree Delete Control

          30 19
          04 17
          2.16.840.1.113730.3.4.2 : Manage DSA IT LDAPv3 control

          1.0.1 :
          -------
          30 30
          02 01 0A : MessageId = 10
          4A 2B : Delete request
          cn=testDelete,ou=appli,ou=frisco,O=INTERNET

          Show
          Emmanuel Lecharny added a comment - Ok, I think I know what's going on. The 1.2.0 request contains a Tree Delete control, which only administrators can use, so you get the permission error. This has been added in 1.2.0. If the rootDSE contains this control, then the delete request is send with it added. Obviously, when you are not an admin on IDS, you will get a failure ... ( http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahycontrols.htm ) There is no workaround, except than using an older version ... A fix would be to modify the Delete selection on the browser to ask if the user want to apply the TreeDelete control or not, plus a preference to set it by default, or not. Here are the two decoded PDU : 1.2.0 : ------- 30 67 02 01 10 : MessageId = 16 4A 2B : Delete request cn=testDelete,ou=appli,ou=frisco,O=INTERNET A0 35 : Controls 30 18 04 16 1.2.840.113556.1.4.805 : Tree Delete Control 30 19 04 17 2.16.840.1.113730.3.4.2 : Manage DSA IT LDAPv3 control 1.0.1 : ------- 30 30 02 01 0A : MessageId = 10 4A 2B : Delete request cn=testDelete,ou=appli,ou=frisco,O=INTERNET
          Hide
          Dominique Jean-Prost added a comment -

          Well I'm glad you manage to find the problem.
          Actually, the user I use to browse my ldap is not an adminstrator, strictly speaking. He's a user I granted delete rights to the tree branch I'm working on.
          So from my point of view, I think you should add the option to send or not the TreeDelete Control.
          By the way, if I understood the TreeDelete Control, it should only apply to non leaf nodes, shouldn't it ? In my case, I try to delete a leaf, so why does this control come in the game ?

          Show
          Dominique Jean-Prost added a comment - Well I'm glad you manage to find the problem. Actually, the user I use to browse my ldap is not an adminstrator, strictly speaking. He's a user I granted delete rights to the tree branch I'm working on. So from my point of view, I think you should add the option to send or not the TreeDelete Control. By the way, if I understood the TreeDelete Control, it should only apply to non leaf nodes, shouldn't it ? In my case, I try to delete a leaf, so why does this control come in the game ?
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Hi Dominique,

          That's a good idea, you should create a JIRA about letting the user decide in the preferences to use or not this control, so we can fix that before version 1.2.0 (final) comes out.

          I think this control comes in the game because we don't know we're dealing with a node or a leaf until we've get children of the item. So I think the default behavior is acting as if the entry is a node.

          Show
          Pierre-Arnaud Marcelot added a comment - Hi Dominique, That's a good idea, you should create a JIRA about letting the user decide in the preferences to use or not this control, so we can fix that before version 1.2.0 (final) comes out. I think this control comes in the game because we don't know we're dealing with a node or a leaf until we've get children of the item. So I think the default behavior is acting as if the entry is a node.
          Hide
          Emmanuel Lecharny added a comment -

          There is no way for the client to know if an entry has some children, unless you do a search with a one-level scope. So we can't determinate if we have to add the Delete Tree control or not, otherwise it would lead to a potentially costly search request for nothing.

          Show
          Emmanuel Lecharny added a comment - There is no way for the client to know if an entry has some children, unless you do a search with a one-level scope. So we can't determinate if we have to add the Delete Tree control or not, otherwise it would lead to a potentially costly search request for nothing.
          Hide
          Dominique Jean-Prost added a comment -

          Pierre-Arnaud,

          Don't you think the real problem is raised because you use this control, that should only apply to non leaf, on leafs ? I mean :

          • if I try to delete a leaf, this control should not be used
          • if I try to delete a branch, this control should always be used (because of security issue on server side).

          If you did that, I wouldn't meet the problem, and I would accept that I'm not allowed to delete a tree if I'm not allowed to (because of the tree delete control). I would have to delete the branch leaf by leaf until my branch is completely deleted, which would allow me to delete branch, although the control would have prevented me to achieve it, which is completely stupid to my mind.

          Show
          Dominique Jean-Prost added a comment - Pierre-Arnaud, Don't you think the real problem is raised because you use this control, that should only apply to non leaf, on leafs ? I mean : if I try to delete a leaf, this control should not be used if I try to delete a branch, this control should always be used (because of security issue on server side). If you did that, I wouldn't meet the problem, and I would accept that I'm not allowed to delete a tree if I'm not allowed to (because of the tree delete control). I would have to delete the branch leaf by leaf until my branch is completely deleted, which would allow me to delete branch, although the control would have prevented me to achieve it, which is completely stupid to my mind.
          Hide
          Dominique Jean-Prost added a comment -

          As you posted your comment, I was writing mine...

          So you tell me you can't know if you're a leaf. OK.

          So, do I need to open an other jira to report this enhancement, or does this one is enough ?

          Show
          Dominique Jean-Prost added a comment - As you posted your comment, I was writing mine... So you tell me you can't know if you're a leaf. OK. So, do I need to open an other jira to report this enhancement, or does this one is enough ?
          Hide
          Dominique Jean-Prost added a comment -

          what is aimed the preferences/ldap/browser/check for children option at ? isn't it for the problem we're talking about ?

          Show
          Dominique Jean-Prost added a comment - what is aimed the preferences/ldap/browser/check for children option at ? isn't it for the problem we're talking about ?
          Hide
          Emmanuel Lecharny added a comment -

          The best would be to create another JIRA where you explain that the Delete Tree control should not be used automatically, but only if the user either specify it for a delete request, or if it's set in a preference.

          Then you will be able to close this issue, and make a link between the new issue and this one.

          But you can also prefer not create a new issue, as this one is pretty much self explanatory.

          It's up to you !

          Btw, thanks for this clear report, it was not an obviou bug, I'm glad you found it !

          Show
          Emmanuel Lecharny added a comment - The best would be to create another JIRA where you explain that the Delete Tree control should not be used automatically, but only if the user either specify it for a delete request, or if it's set in a preference. Then you will be able to close this issue, and make a link between the new issue and this one. But you can also prefer not create a new issue, as this one is pretty much self explanatory. It's up to you ! Btw, thanks for this clear report, it was not an obviou bug, I'm glad you found it !
          Hide
          Stefan Seelmann added a comment -

          I would suggest the following solution:

          For 1.2.0 I'll add an interims solution.

          • try to delete the entry, without any control
          • if that fails with error 66 AND the server supports the tree delete control then ask if the tree delete contol should be used

          For 1.3.0 I would suggest to create a new connection property page and a new connection wizard page that allows the user to enable/disable all supported controls. I'd like to make this configurable per connection, not only per global preferences. This way I is possible to configure directory specific features for each connection.

          Thoughts?

          Show
          Stefan Seelmann added a comment - I would suggest the following solution: For 1.2.0 I'll add an interims solution. try to delete the entry, without any control if that fails with error 66 AND the server supports the tree delete control then ask if the tree delete contol should be used For 1.3.0 I would suggest to create a new connection property page and a new connection wizard page that allows the user to enable/disable all supported controls. I'd like to make this configurable per connection, not only per global preferences. This way I is possible to configure directory specific features for each connection. Thoughts?
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Stefan,

          I like your ideas.

          The solution for 1.3.0 will really be a huge improvement.

          For 1.2.0, the user will receive a MessageDialog where he choose to use or not the Tree Delete Control, right ?
          If he chooses not to use it, then will Studio be deleting all the child nodes first (before deleting the selected entry)?

          Thanks

          Show
          Pierre-Arnaud Marcelot added a comment - Stefan, I like your ideas. The solution for 1.3.0 will really be a huge improvement. For 1.2.0, the user will receive a MessageDialog where he choose to use or not the Tree Delete Control, right ? If he chooses not to use it, then will Studio be deleting all the child nodes first (before deleting the selected entry)? Thanks
          Hide
          Emmanuel Lecharny added a comment -

          +1 to both suggestions

          Show
          Emmanuel Lecharny added a comment - +1 to both suggestions
          Hide
          Stefan Seelmann added a comment -

          Yes Pierre-Arnaud, you perfectly described my thoughts

          Show
          Stefan Seelmann added a comment - Yes Pierre-Arnaud, you perfectly described my thoughts
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Great!

          +1

          This is perfect.

          Show
          Pierre-Arnaud Marcelot added a comment - Great! +1 This is perfect.
          Hide
          Stefan Seelmann added a comment -

          Added an option to the delete dialog to enable/disable the tree delete control.

          Fixed in trunk and 1.2.x branch:
          http://svn.apache.org/viewvc?rev=684194&view=rev
          http://svn.apache.org/viewvc?rev=684195&view=rev

          Show
          Stefan Seelmann added a comment - Added an option to the delete dialog to enable/disable the tree delete control. Fixed in trunk and 1.2.x branch: http://svn.apache.org/viewvc?rev=684194&view=rev http://svn.apache.org/viewvc?rev=684195&view=rev
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Apache Directory Studio 1.2.0 has now been released.

          Let's clean Jira and close this issue.

          Show
          Pierre-Arnaud Marcelot added a comment - Apache Directory Studio 1.2.0 has now been released. Let's clean Jira and close this issue.

            People

            • Assignee:
              Stefan Seelmann
              Reporter:
              Dominique Jean-Prost
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development