directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Seelmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSTUDIO-410) Referral handling is problematic
Date Mon, 06 Oct 2008 22:03:44 GMT

    [ 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.


Mime
View raw message