svn_auth.h has:
/** Initialize an authentication system.
*
* Return an authentication object in @a *auth_baton (allocated in @a
* pool) that represents a particular instance of the svn
* authentication system. @a *auth_baton will remember @a pool, and
* use it to store registered providers.
*/
svn_error_t * svn_auth_open(svn_auth_baton_t **auth_baton,
apr_pool_t *pool);
/** Register an authentication provider.
*
* Register an authentication provider (defined by @a vtable and @a
* provider_baton) with @a auth_baton, in the order specified by
* @a order. Use @a pool for any temporary allocation.
*/
svn_error_t * svn_auth_register_provider(svn_auth_baton_t *auth_baton,
int order,
const svn_auth_provider_t
*vtable,
void *provider_baton,
apr_pool_t *pool);
--/--
This means that a provider is only within the scope of a particular
baton. This troubles me as I wonder the interaction of the
registration here. If we have a DSO that provides an authentication
provider, how do we register it? Do we require explicit
fore-knowledge of authentication providers in a client (i.e. the
client explicitly calls register provider for all the providers it
knows it will have - i.e. what we do in
subversion/libsvn_ra/ra_loader.c)?
To me, that seems a bit constraining. I guess I'd rather see auth
providers have the ability to register themselves. My goal would be
to have a 'special' directory where I can throw in new auth
providers. (I'd also like to do this for ra's, but it's too late for
that, I think.)
How do you see such a model working with this scheme where multiple
auth batons can co-exist simultaneously each with different
providers? Or, are we forced to hard-code known auth providers? --
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:12:35 2006