[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Semantics of svn_auth_save_credentials?

From: <sussman_at_collab.net>
Date: 2003-01-24 17:59:41 CET

Justin Erenkrantz jerenkrantz@apache.org 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,
                                         void *credentials,
                                         svn_auth_baton_t *auth_baton,
                                         apr_pool_t *pool);
 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,
                                     void *credentials,
                                     void *provider_baton,
                                     apr_pool_t *pool);

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'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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:13:55 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.