On Mon, 2005-11-21 at 11:13 -0800, Kurt D. Zeilenga wrote:
In theory, the slave could attach a post-readEntry control to
chaining operation wrapping the the modify request and use
the returned entry to "pre-sync" the value. Of course,
syncrepl would then need to ignore changes to that
entry that have an later CSN.
Note that use with a chaining operation is necessary here
for two reasons:
1) to avoid conflict with any client provided read
entry control, and
2) appropriate authorization (e.g., as slave not
client).
Of course, the devil is in the details.
Talking about details, one of the reasons we'd need a chaining operation
is to avoid conflicts with client provided controls; it seems, from your
suggestion, that the authorization as the client should be added by the
chaining layer to the client's operation (the sub-operation), thus
potentially conflicting with client-provided authorizations. If we were
to add the authorization to the outer controls set (those of the
chaining operation) then the post-read would still occur with the
client's identity, and the whole thing would not work. The chaining
operation would need the possibility to handle layers of nesting for
things like controls, so that:
chainedOperation
- layer 1: ... (<none>)
- layer 2: proxyAuthz; ...
...
- sub-operation
...
- layer 2: ... (<none>)
- layer 1: postRead; ...
chainedResponse
In this case, the scope of the postRead would be outside that of the
proxyAuthz, so the original identity (i.e. that of the replicator) would
be used instead of that of the client.
Another possibility is to extend <draft-weltman-ldapv3-proxy> to support
cascaded authorizations, so that a sequence of identities can be
provided instead of just one, and they are applied in the provided
order, each time applying server side constraints (that is,
authzTo/AuthzFrom policies).