Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.5.0
    • Component/s: None
    • Labels:
      None

      Description

      The way referrals are handled in the server is problematic.

      There is a mix between JNDI and plain LDAP (ManageDsaIT control usage).

      Beside the fact that one should be able to select the way referral should be handled on each request (it's painful to have to disconnect when you change the global property), for people used to deal with JNDI, the 'manage' option does not make sense.More than that, 'manage' defaults to 'ignore' (which is plain OK, so far), but the 'ignore' option is not activated.

      I would suggest that we switch to 'ignore', 'throw' and 'follow' instead of 'follow', 'ignore' and 'manage'

        Activity

        Hide
        Stefan Seelmann added a comment -

        The three options for "referral handling" have nothing in common with the JNDI modes. IMHO the Studio users should not care about the referral handling of JNDI. My intention was to give the user some options how s/he wants to manage LDAP referrals. Maybe we could find better terms. Let me describe what I intented:

        follow:

        • sends no ManageDsaIT control
        • if the server returns a referral (either a continuation reference for a search or a referral for on a modification request) the URL is presented to the user and s/he could select the right target connection. You may ask "why not just use the host from the referral URL?". The reason is that a referral URL doesn't contain any authentication or security information. If you search as anonymous and you receive a referral which target server needs stonger authentication it is not possible to follow it automatically, but the selected connection could have the right authentication paramters.

        ignore:

        • sends no ManageDsaIT control
        • occuring referrals are ignored, they are neither displayed nor any errors are shown to the user

        manage:

        • sends the ManageDsaIT control with each request, so the server returns the referral entries
        • displays returned referral entries, so the user could modify them.

        But you are right that referral handling is not ideally solved in Studio. We should think about how to handle it better. Your issue DIRSTUDIO-402 is a first step. We have to consider two cases: search continuations and referrals for add/modify/delete/moddn requests.

        BTW: The JNDI property "java.naming.referral" in the Studio code is always set to "throw" because we handle occuring referrals manually in the Studio code, this way we have more control. With the "follow" value JNDI follows the referral internally, this may be more comfortable for a programmer but we won't be able to display the URL in the browser. And the "ignore" value is the wrong name for this options IMO, it always sends the ManageDsaIT control.

        Show
        Stefan Seelmann added a comment - The three options for "referral handling" have nothing in common with the JNDI modes. IMHO the Studio users should not care about the referral handling of JNDI. My intention was to give the user some options how s/he wants to manage LDAP referrals. Maybe we could find better terms. Let me describe what I intented: follow: sends no ManageDsaIT control if the server returns a referral (either a continuation reference for a search or a referral for on a modification request) the URL is presented to the user and s/he could select the right target connection. You may ask "why not just use the host from the referral URL?". The reason is that a referral URL doesn't contain any authentication or security information. If you search as anonymous and you receive a referral which target server needs stonger authentication it is not possible to follow it automatically, but the selected connection could have the right authentication paramters. ignore: sends no ManageDsaIT control occuring referrals are ignored, they are neither displayed nor any errors are shown to the user manage: sends the ManageDsaIT control with each request, so the server returns the referral entries displays returned referral entries, so the user could modify them. But you are right that referral handling is not ideally solved in Studio. We should think about how to handle it better. Your issue DIRSTUDIO-402 is a first step. We have to consider two cases: search continuations and referrals for add/modify/delete/moddn requests. BTW: The JNDI property "java.naming.referral" in the Studio code is always set to "throw" because we handle occuring referrals manually in the Studio code, this way we have more control. With the "follow" value JNDI follows the referral internally, this may be more comfortable for a programmer but we won't be able to display the URL in the browser. And the "ignore" value is the wrong name for this options IMO, it always sends the ManageDsaIT control.
        Hide
        Emmanuel Lecharny added a comment -

        The biggest problem I see is that JNDI 'ignore' semantic is the opposite to what you have implemented with the 'ignore' option : it always send the ManageDsaIT control. The idea is that JNDI should 'ignore' the referral characteristic of the entry, and just consider it as a normal entry, instead of sending back a Referral result.

        I'm afraid that those who are using Studio may be tainted by JNDI... (btw, the 'follow' option is a typical JNDI option).

        Anyway, what I would suggest is that we propose something more in line with what really happens : instead of using one word, express the referral handling processing. Something like :

        • Follow referrals
        • Ignore referrals
        • Ask the users (ie, throw)

        wdyt ?

        Show
        Emmanuel Lecharny added a comment - The biggest problem I see is that JNDI 'ignore' semantic is the opposite to what you have implemented with the 'ignore' option : it always send the ManageDsaIT control. The idea is that JNDI should 'ignore' the referral characteristic of the entry, and just consider it as a normal entry, instead of sending back a Referral result. I'm afraid that those who are using Studio may be tainted by JNDI... (btw, the 'follow' option is a typical JNDI option). Anyway, what I would suggest is that we propose something more in line with what really happens : instead of using one word, express the referral handling processing. Something like : Follow referrals Ignore referrals Ask the users (ie, throw) wdyt ?
        Hide
        Stefan Seelmann added a comment -

        I changed the referral handling options in the connection properties, see options and descriptions below:

        • Follow Referrals automatically:
          Follows referrals and search continuations immediately if they are received from the directory server. You are asked which connection you want to use to follow a specific referral URL, this way you have full control regarding encryption and authentication options when following referrals.
        • Follow Referrals manually:
          Received referrals and search continuations are just displayed in the Browser. As soon as you open or expand such an search continuation the search is continued. You are asked which connection you want to use to follow a specific referral URL, this way you have full control regarding encryption and authentication options when following referrals.
        • Ignore Referrals:
          Any referral or search continuation received from the directory server is silently ignored. No error is logged, no dialog appears, no special entry is displayed in the DIT, no ManageDsaIT control is sent to the server.

        Especially the "Manage" option is removed, instead the "Controls" section now contains an option "Use ManageDsaIT control while browsing", if activated the control is sent with each request. It is also possible to send the ManageDsaIT control per request by selecting "Fetch > Fetch Referrals" from the browser context menu.

        Show
        Stefan Seelmann added a comment - I changed the referral handling options in the connection properties, see options and descriptions below: Follow Referrals automatically: Follows referrals and search continuations immediately if they are received from the directory server. You are asked which connection you want to use to follow a specific referral URL, this way you have full control regarding encryption and authentication options when following referrals. Follow Referrals manually: Received referrals and search continuations are just displayed in the Browser. As soon as you open or expand such an search continuation the search is continued. You are asked which connection you want to use to follow a specific referral URL, this way you have full control regarding encryption and authentication options when following referrals. Ignore Referrals: Any referral or search continuation received from the directory server is silently ignored. No error is logged, no dialog appears, no special entry is displayed in the DIT, no ManageDsaIT control is sent to the server. Especially the "Manage" option is removed, instead the "Controls" section now contains an option "Use ManageDsaIT control while browsing", if activated the control is sent with each request. It is also possible to send the ManageDsaIT control per request by selecting "Fetch > Fetch Referrals" from the browser context menu.
        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:
            Emmanuel Lecharny
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development