Re: (ITS#4570) slapo-chain does not return an error when chasing a referral fails

[michail.bachmann@cms.hu-berlin.de]

On Tuesday 30 May 2006 17:53, Pierangelo Masarati wrote:
> > When the chain overlay encounters an error while chasing a referral it
> > will
> > return the chased referral to the client instead of the occured error.
>
> This behavior is consistent with that of libldap, and I believe it is
> desirable. 

Unfortunately it is inconsistent: You get the correct behaviour if everything 
went all right, but not the real error message if something went wrong. In 
fact you fall back to the behaviour of libldap which IMO minimizes the 
usefullness of this overlay.

> In fact, slapo-chain tries to chain operations when possible; 
> when it's not, the referral is returned to the client under the assumption
> the client may know how to deal with referrals that couldn't be
> automatically chased. 

It is this assumption I find questionable. Often the server is in a much 
better position (e.g. proxy or slave) to chase the referral, especially as 
very few clients actually implement referral chasing.

> This is true, for example, in cases where a 
> referral needs to be chased with an identity that differs from that used
> for the original request, and I guess this is your case: slapo-chain is
> receiving an "inusufficientAccess" code.
> Or maybe you need to use the "idassert" feature so that the identity your
> client bound with is asserted while chasing the referral by means of the
> proxyAuthz control (RFC4370); see slapd-ldap(5) for details.

I am already using it. But because the ACLs are not checked before chasing the 
referral and the actual error message is not returned, this overlay is not as 
usefull as I thought at first.

> If you need a different behavior, e.g. that no referrals ever get
> returned, you may want to look into using the "chainingBehavior" control
> <draft-sermersheim-ldap-chaining> (expired), which is implemented in
> slapo-chain(5).  The code might be a little bit broken as it's never been
> revitalized after the draft expired.

Yes, I have already looked into it. Is it foreseeable whether this control 
will stay or are there plans to remove it?

Mit freundlichen Gruessen

Michail Bachmann

-- 
ZE Computer- und Medienservice der Humboldt-Universitaet zu Berlin
phone: +49.30.2093.2191
Raum 1064b, Unter den Linden 6, D-10099 Berlin, Germany