You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Seelmann (JIRA)" <ji...@apache.org> on 2008/10/07 00:03:44 UTC

[jira] Commented: (DIRSTUDIO-410) Referral handling is problematic

    [ https://issues.apache.org/jira/browse/DIRSTUDIO-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637267#action_12637267 ] 

Stefan Seelmann commented on DIRSTUDIO-410:
-------------------------------------------

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.




> Referral handling is problematic
> --------------------------------
>
>                 Key: DIRSTUDIO-410
>                 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-410
>             Project: Directory Studio
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>
> 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'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.