Re: authentication storage question

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

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