Re: Semantics of svn_auth_save_credentials?

--On Friday, January 24, 2003 10:59 AM -0600 Ben Collins-Sussman
sussman@collab.net wrote:

 In other words, a provider can refuse to save. For example, the
 provider which prompts people for username/password -- it makes no
 sense for it to know how to save anything. But a provider which
 fetches data from .svn/auth/ or ~/.subversion/ should know how to
 store data.

 libsvn_auth just walks over each provider in turn, until some
 provider claims to have saved the data.

I guess I'd rather see the saving correlated with the provider.

Imagine this scenario:

1) User backing store #1 (file)
2) User backing store #2 (dbm)
3) Keyboard

Say we find a match in provider #2 (all the ones in provider 1 fail).
We authenticate successfully. Furthermore, let's add the assumption
that we're fairly advanced and we have a procedure within the client
to change the user's password. So, we now update the credentials for
this user with a new password.

What would be nice would be to replace the old credentials in the dbm
with the new one. So, if we were to store the originating provider
as a key in the credentials, we could then 'update' the credentials.

Now, you could say that because the user placed the 'file' provider
first that that is their 'preferred' provider. But, I'm not sure
that's exactly what we would want. Is it? -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:14:04 2006