Re: authentication storage question

Ben Collins-Sussman wrote:

>I'm in the middle of rewriting the client-side authentication system,
>and people are right: it's much simpler and cleaner to have "RA pull
>info from client when challenged", rather than "client preemptively
>push data at RA". Many problems drop away, and code gets smaller.
>
>I have one design problem, though.
>
>Here's a typical code flow:
>
> 1. client calls
>
> session_baton = RA->open (URL, vtable_of_callbacks)
>
>
> 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.)
>
> * authentication suceeds, so RA finishes its work. or
> authentication fails, and user sees immediate error.
>
>
> 3. client repeats step 2 until finished, then calls
>
> RA->close (session_baton)
>
>
>Here's the missing feature: if authentication was successful, it's
>very likely that the auth info needs to be stored somewhere on the
>client. (IOW, cached for next time. We're already doing this in our
>current auth system.)
>
>How does the client know if info needs to be stored? Or which info
>needs to be stored?
>
>- One possibility is that each RA->do_something() call return this
> information.
>
>- Another possibility is that RA->close() is the only call to return
> this information.
>
>- 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.
>
>Thoughts? I think the third idea is probably best.
>
I think so, too. Right now, the client stores auth data if the RA
operation is successful -- which means that if, e.g., a checkout fails,
the auth data will not be cached, even if the authentication itself is
O.K. I ran into this while I was fixin co on Windows, and got mighty
bored by the username prompts.

So: cache the auth data as soon as authentication succeeds, and since a)
only the RA layer knows when that happens, and b) only the client knows
how to archive the data, the third idea is the only one that works.

BTW, what's in the RA callback vtable? IIRC:

    * open_temp_file (open a temporary file, returns apr_file_t)
    * close_temp_file (close and delete temporary file)
    * get_auth_data (pull authentication data from the client, in some
      generic format)
    * store_auth_data (archive the authentication data)

-- 
Brane �ibej   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org