[Date Prev][Date Next]
Re: Dropping slurpd, manage/Relax control
At 08:36 AM 12/14/2006, Howard Chu wrote:
>The new mechanism wouldn't behave a whole lot differently... If we were to make this a control I would only define it for Bind operations, thus identifying an entire session to be a server-to-server interaction.
I would hesitate a bit on making this a bind control. First,
bind controls are not protected by the Bind's authentication
mechanism. Second, there are likely cases where a client
was to act as a DSA and act as a client. Adding a simple
control (no control data) doesn't add much overhead...
>It doesn't make sense to me to attach such a control on a per-operation basis. But once we've established that the peer is a server, we can simplify a lot of other checks. (E.g., set a boolean in the Connection structure, instead of having to compare DNs all the time.)
We, of course, could do this with updatedn. That is, check the
authzDN after the bind completes and set a flag (and clear it
>This would give us the freedom to do a bit more along the lines of X.500 DSP without the ambiguity that the current chaining/proxyauth/etc. approaches suffer from.