Pierangelo Masarati wrote:
[moved to -devel for discussion]
On Fri, 2005-09-30 at 18:39 +0000, [EMAIL PROTECTED] wrote:
Finally I think it is a configuration problem : a special case of
recursive referral.
I think you can close this ITS or change it in a feature request to detect
this special bad configuration :
Server 1 with back-ldap pointing to server 2.
Server 2 with back-bdb with a referral to server1.
I think we need to design some procedure to detect this type of issues.
In fact, now that back-ldap is being used for a number of applications
that may give rise to circular referral conditions (proxy, chain, ...),
the referral mechanism appears somewhat inadequate. In fact, it doesn't
allow a built-in and standardized way to keep track of its history
and/or at least count. While this might be food for thought for the
ldapbis list, the current implementation of the proxy and of the chain
overlay would really need this. For example, the current implementation
of the chain overlay violates draft-ietf-ldapbis-protocol where it
states
Clients that follow referrals MUST ensure that they do not loop
between servers. They MUST NOT repeatedly contact the same server for
the same request with the same parameters. Some clients use a counter
that is incremented each time referral handling occurs for an
operation, and these kinds of clients MUST be able to handle at least
ten nested referrals while progressing the operation.
because in this case it is __not__ the client library that follows
referrals and counts the number of referrals that have been followed
(thus limiting recursion by limiting the maximal count of referrals
chased, instead of keeping track of the values that were chased). With
back-ldap and with proxies in general, there is no way to determine if a
request comes as a consequence of a referral chasing.
Maybe we could add some sort of control that appends a cookie to
requests and instructs the server to propagate that cookie when chasing
referrals or proxying the request. The appearance of the cookie in a
request to a server, when the cookie originated from that server for
that very request, would indicate a circular reference. I think there
is more to think about this (servers that do not implement this control
would destroy its usefulness; we need a specific control to implement
something that should be granted anyway according to draft-ietf-ldapbis-
protocol; each sub-request performed to satisfy the initial one would
need to be appended to the cookie because the circular reference may
start at any level of nested request; ...).
Just more evidence of the poor design choices that we're stuck with in
LDAP; trying to use a client-server protocol for server-server
operations is always going to run into this type of problem. And
referrals in general have always been a weak spot in the LDAP design.
I think you may be able to attach a cookie to the request by adding an
item to the search filter. Yes, this is a hack, but obviously you need
something that works today, and this should work without breaking
anything else.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
