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

Re: authentication storage question

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-16 20:29:45 CEST

On Sat, Sep 15, 2001 at 11:00:10AM -0500, Ben Collins-Sussman wrote:
> 1. client calls
> session_baton = RA->open (URL, vtable_of_callbacks)

Note that there should probably be a baton associated with that vtable.

> 2. client calls
> RA->do_some_network_things (session_baton)
> * the RA layer is challenged by Apache
> * the RA layer uses the callback vtable to get information from
> the client. (the client has its own logic for getting info
> from argv[], or files, or user-prompts.)

Data comes via the baton, right? :-)

> - Another idea is to have RA do the auth storage itself, via another
> vtable callback. Each RA routine would have to remember to do this
> before returning.

The latter. When RA fetches an authenticator, it should get a baton. In the
authenticator vtable, there is a "store auth info" entry.

So... the client-provided vtable looks something like:

* open_tempfile(client_baton, pool, &file)
* close_tempfile(file)
* get_authenticator(which_method, client_baton, pool, &auth_vtable, &auth_baton)

[ we may not need close_tempfile; APR files already have a "delete on close"
  and there is also a patch floating for APR to create temp files as
  appropriate for the platform at hand (e.g. TMP/TEMP/TMPDIR on Windows, or
  mkstemp() on unixen, etc) ]

And the authenticator vtable looks like:

* authenticate(auth_baton)
* save_authinfo(auth_baton)
* ... functions appropriate to this auth method


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 21 14:36:41 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.