NOTE: Ben and I just spoke for about an hour on the phone, and with Karl in
there for about 15 minutes. Ben is going to brain dump that in just a bit.
On Fri, Jan 31, 2003 at 11:19:20AM -0800, Justin Erenkrantz wrote:
> --On Friday, January 31, 2003 12:49 PM -0600 Ben Collins-Sussman
> <sussman@collab.net> wrote:
>...
> Okay, so there are two problems here:
>
> - Registration is happening too late in the game for the client to
> have control it requires
s/client/app/ for clarity. And yes, correct.
> - Passwords are still stored in the WC rather than in ~/.subversion.
This *should* continue to be possible. The auth system should not preclude
this type of behavior.
The root problem is that we cannot parameterize the provider at "runtime"
once we know further information. I previously gave an example of a Basic
auth request where the server tells use the Realm to use. Not to mention the
hostname (or UUID) that we eventually decide to contact.
Ben and I talked about a way to handle this. See his upcoming proposal.
>...
> Oooooh, even better, we still need to pass the repos UUID anyway to
> the first_cred function. Perhaps we could have a special case of the
> repos UUID passed to first_cred that indicates that it is a WC dir
> not a UUID (presence of a / in the first character?). Hmm. I think
> that might not be a bad idea. Kill two birds with one stone. Any
We've got a clean solution :-)
>...
> Because it means that you are making them symmetrical in all
> read/write operations. To me, that indicates something got lost. It
> should be possible for one set of credentials to be created by a
> provider, then saved by another one. You only seem to want to be
> able to keep it within one provider. I don't think that's what we
> initially wanted.
Right; that was the original intent.
Note that there is a potential ordering problem, similar to the kinds of
module-related ordering problems in Apache 1.3. The order that you retrieve
might not be the order that you want to save. The "right" answer (which is
what Apache 2.0 did) is to have separate lists: one for fetching and one for
saving (A2 does this with the hooks each being their own ordered list rather
than a global module-ordered list).
However, two lists would be a pain, and is only to solve boundary cases. The
proposal continues with a single list, but points out that you can
instantiate providers (e.g. the provider_baton contents) differently to
produce different behavior in your overall provider list.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 22:54:26 2003