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

[Kurt@OpenLDAP.org]

On Jan 26, 2011, at 9:15 AM, masarati@aero.polimi.it wrote:

> The complexity of handling this nonsense in libldap seems not worth =
the
> effort;

Ando, you are too kind to refer this extension as 'nonsense'.  It's =
worse than nonsense, it's crap.

The spec you pointed at says: "LDAP servers often place limits on the =
maximum number of attribute values that can be retrieved in a single =
query."  The spec fails to say why would a server want to do that.  I =
cannot think of any good reason to do precisely that.  While I can =
understand a desire to place limits on what clients can retrieve, I =
don't see why one would distinguish between a single query and a set of =
queries.  I can also see it desirable to allow a client to page through =
results (but that's a different matter, this is about forcing paging =
onto clients).

It is incredibly stupid to require clients to use multiple operations to =
obtain information for which the protocol allowed to be fetched in a =
single operation, and this is why I refer to this as "crap".

A major problem with paging, whether server-forced or at client-option, =
is result set coherency due to changes to the DIT between when various =
page operations are obtain.  This can lead to problems such a member of =
a group not appearing in the results.  While one might argue client =
might be able to reasonable deal with coherency issues, most client =
developers won't.  This will lead to a range of security issues creeping =
into directory applications.

So while I don't generally oppose introduction of paging extensions at =
the client option, I think the specifications should warn that the =
clients using them need to be designed to handle data coherency issues. =
However, most designers of such extensions seem to have put no thought =
into this issue at all.

I do generally oppose introduction of non-truly optional extensions in =
LDAP (and in other application protocols).   One would think that a =
requirement that extensions to a protocol be truely optional would go =
without saying, but in IETF we actually found it necessary to explicitly =
state this in the BCP governing LDAP extensions.

That BCP will effectively stop non-truly optional extension proposal as =
this from gaining Standard Track status in the IETF.

> 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 would think it easier to reconfigure AD not to have the limits which =
cause this sort of paging.

> 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.
>=20
> 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).
>=20
> p.