--On Friday, January 31, 2003 12:49 PM -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:
> Impossible. Tried it.
>
> The provider which loads/saves from the wc can't be constructed
> until we're way inside libsvn_client. Our svn_client_* routines
> each do all sorts of individual argument processing, deciding which
> things are paths, urls, etc. It isn't until the moment
> svn_client_foo() is ready to open an RA session that it decides it
> has a wc path. Once it has that wc path, it can create the
> wc-provider.
Okay, so there are two problems here:
- Registration is happening too late in the game for the client to
have control it requires
- Passwords are still stored in the WC rather than in ~/.subversion.
Remember we agree that we *must* not be storing the credentials in
the WC as that is a security violation. It should be doomed for
extinction soon.
Here's what I believe *should* be happening:
- Auth baton is created by the client program
- Providers are registered in a certain order as the client likes
- Auth baton passed into all libsvn_client functions (svn_client_ctx?)
- libsvn_client uses the auth baton when required.
Remember I was warning about the scope of the providers. You are
making the scope of the providers WC-centric when they should not be
- they are essentially global (at the same lifetime as the auth baton
which the client creates).
A temporary solution (until we migrate everyone's cache to
~/.subversion/) is to pass the WC directory to the first_cred
function. I think we would be able to eliminate it when we eliminate
the WC-password storage. We should document that it would go away
around beta time...
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
repos with a UUID will have its authentication stored in
~/.subversion/. If it doesn't have a UUID, then it is implicitly in
the WC (but the ~/.subversion/ central cache wouldn't try there).
Over time the support for WC auth caches go away. (Hint: these
non-UUID repos case *could* still be stored in the central cache.)
This solves the problem of not providing the provider enough context
to find the right auth cache file.
> Why? It's just *one* prompt provider. Your app can implement a
> different one. The one created by libsvn_client is designed to
> cache data.
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.
Here's the perfect use case for why credential storage should be
asymmetrical:
- Use auth credentials from ~/.subversion/
- Use auth credentials from WC
- Prompt
User comes along with older WC that has its credentials stored in the
WC rather than somewhere in ~/.subversion/. When we want to shut off
storing credentials in the WC, we merely take out the save function
in the WC provider. The auth provider code will automatically then
go to the first provider that can save: the one that stores the auth
credentials in ~/.subversion/.
By relying upon this, it makes it easy to upgrade password stores
over time. Relying upon symmetry alone makes it so that the WC-only
provider has to understand the new format as well. Eek. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 20:20:03 2003