[Date Prev][Date Next]
Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
- From: Kurt@OpenLDAP.org
- Date: Wed, 26 Jan 2011 18:11:37 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On Jan 26, 2011, at 9:15 AM, firstname.lastname@example.org wrote:
> The complexity of handling this nonsense in libldap seems not worth =
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 =
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 =
> contains a range in each SearchResultEntry message makes sense.
> The parallel with referrals is not appropriate, since referrals are =
> of LDAP specification; also, please note that automatic referral =
> is strongly discouraged unless the transport layer is protected =
> of RFC 4511).