directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [ApacheDS] Referral handling for DIRSERVER-806
Date Wed, 14 Feb 2007 11:02:04 GMT
In my mind, you just did the good choice. Let's consider the situation where
a user can ask for the 'ref' attribute :
- he asks for all the operationnal attributes ( filter = '+' )
- he asks for 'ref' explicitely
- he get a referral entry, and only if he added the ManageDsaIT control.
- he has created an entry with the 'extensibleObject' OC and added a 'ref'
attribute to this entry, using it for other purpose than referrals

for the 3 first cases, we don't really care about returning 'ref' all the
time : the user will only get it for found referrals, and only if he has
added the ManageDsaIT control. Especially for case 1 and 2, there is no way
he can get a 'ref' attribute (just because referral wont be returned as
entries if the ManageDsaIT is not passed to the server).

For case 4, well, I don't think we should bother. At least for 1.0.1. And
even for 1.0.2. Let's postpone such a case for 1.5.0 (anyway, doe sit harm
someone that a get the 'ref' attribute when he deliberatly added it into a
special entry?)


On 2/14/07, Alex Karasulu <> wrote:
> Hi Emmanuel,
> I started adding code to inject the "ref" attribute into the
> returningAttributes
> property of the SearchControls to enable the detection of a referral.  As
> I was doing
> this I had to make the attribute selection code add all attributes when
> just [ref] was
> found in the returningAttributes field since ref is synthetically
> injected.  Sometimes
> though users will just want to have only the [ref] attribute returned and
> will specify
> that in the returningAttributes list.  There is then no way for to
> differentiate between
> these situations when the user intentionally only requests the ref
> attribute verses
> when the server artificially injects it.
> So instead I altered the core code responsible for selecting attributes to
> always
> return the ref attribute regardless of whether it is specified in the
> returningAttributes
> list or not.  This way if the user just specifies the [ref] attribute only
> that attribute
> will be returned instead of returning it and all the non-operational
> attributes.
> Now we only need to add some code that makes sure the ref attribute is
> removed
> from the entry if the *ManageDsaIT * control is enabled and the user did
> not explicitly
> ask for the ref attribute.  This however is a very rare situation.  Why
> would this
> control be enabled by a client without the intention of getting the ref
> attribute
> when a referral only has a ref attribute in it?  I cannot think of a good
> use case
> for this.  So I'm not going to bother adding code to remove the ref
> attribute at this
> point in time.  Let me know if you think we still should and I can add it.
> Alex

Emmanuel L├ęcharny

View raw message