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

Re: Scope of svn_auth_baton_t and providers?

From: <gstein_at_lyra.org>
Date: 2003-01-24 19:38:04 CET

On Thu, Jan 23, 2003 at 10:08:12PM -0800, Justin Erenkrantz wrote:
 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
                                          void *provider_baton,
                                          apr_pool_t *pool);
 This means that a provider is only within the scope of a particular

The doc feels a bit unclear. The provider vtable should live *at least* as
long as the pool passed to svn_auth_open. Typically, the vtable will live in
the 'static const' data segment.

 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

The application is responsible for calling svn_auth_open and registering the
appropriate set of providers. The application will then pass the auth_baton
to all relevant SVN functions (i.e. pretty much all of them).

 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.)

In this case, it is the application loading those providers and registering
them. A given provider doesn't know whether it applies to the particular
application or not.

Take the prompt provider. That will work for the cmdline client, but not
for gsvn. Thus, you can't have some /usr/lib/subversion/providers/ with a
bunch of them that get auto-loaded.

 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? --

There shouldn't be any problem with multiple auth_batons running around the
system. The provider should not have any global state -- it should be
retained entirely in the provider_baton.


Greg Stein, http://www.lyra.org/
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:53 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.