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
*vtable,
void *provider_baton,
apr_pool_t *pool);
--/--
This means that a provider is only within the scope of a particular
baton.
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
subversion/libsvn_ra/ra_loader.c)?
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? --
justin
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.
Cheers,
-g
--
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