[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD

Hash: SHA1

On 01/26/2011 12:15 PM, masarati@aero.polimi.it wrote:
> The complexity of handling this nonsense in libldap seems not worth the
> effort; I think we might consider working this around in proxy backends
> (much like we did for unsolicited paged results response in back-meta,
> ITS#6664, which could be added to back-ldap as well).
> I don't think implementing something that requires a theoretically
> unbounded number of nested search requests for each attribute value that
> contains a range in each SearchResultEntry message makes sense.

I didn't suggest that it should be enabled by default. I was looking for
an option that could be set if a particular client needs it.

> The parallel with referrals is not appropriate, since referrals are part
> of LDAP specification; also, please note that automatic referral chasing
> is strongly discouraged unless the transport layer is protected (Section 6
> of RFC 4511).

Right, I really only meant in the broad sense of "You can enable this
option if you really need it, knowing that there are risks and the
potential for going through multiple additional requests". I just meant
there was precedent for adding features that required extra trips to the

I also fully agree that the range extension is a crime against decency,
but unfortunately it's backed by the 800-pound gorilla that we can't
just ignore. I think if we're stuck with it, it makes sense to put the
code to deal with it in common OpenLDAP library code instead of forcing
every consumer to rewrite it. Because at the end of the day, pretty much
every LDAP client is going to need to be able to talk to Active
Directory at some point.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/