Justin Erenkrantz email@example.com writes:
Within svn_auth.h, we have:
/** Save a set of credentials.
* Ask @a auth_baton to store @a credentials (of type @a cred_kind)
* for future use. Presumably these credentials authenticated
* successfully. Use @a pool for temporary allocation. If no
* provider is able to store the credentials, return error.
svn_error_t * svn_auth_save_credentials(const char *cred_kind,
I have to say that the implied semantics trouble me. Exactly what
provider should 'save' a particular credential? The first provider?
All of them?
If you read the documentation for the provider vtable, you'll see:
/** Save credentials.
* Store @a credentials for future use. @a provider_baton is
* general context for the vtable. Set @a *saved to true if the
* save happened, or false if not. (The provider is not required to
* save; if it refuses or is unable to save, return false.)
svn_error_t * (*save_credentials) (svn_boolean_t *saved,
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
libsvn_auth just walks over each provider in turn, until some provider
claims to have saved the data.
I'd also suggest that a provider be allowed to have a NULL function
pointer to save_credentials rather than implement a stub that returns
false. That makes it much easier for providers - a little more work
for the caller perhaps. -- justin
Sure, that's a good idea. I'll add that as an option. Thus a
provider can do any number of things:
1. not implement a save function at all
2. implement a save function, but refuse/fail to save for nonfatal reasons
3. implement a save function, but throw a *real* error when trying to save
4. implement a save function, and complete the save successfully.
Only libsvn_auth has to understand the conditions... I'll make it so.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 14 02:13:55 2006