Re: authentication storage question

On Sun, Sep 16, 2001 at 05:46:22PM -0500, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > And the authenticator vtable looks like:
> >
> > * authenticate(auth_baton)
> > * save_authinfo(auth_baton)
> > * ... functions appropriate to this auth method
>
> Authenticator? We have no more authenticator objects.

Euh. We should...

> Here's my latest draft of svn_ra.h. I'm almost done rewriting
> svn_client_* routines and the two RA implementations to use it.

Should have posted the header before rewriting :-)

>...
> /* A structure that represents an RA layer's desire to pull
> authentication information from the client; this information can be
> retrieved either by prompting the user, or by retrieving it from a
> file, etc. It's up to the client to decide how to retrieve the
> info. */
> typedef struct svn_ra_get_info_t
> {
> /* A flag which identifies the exact info being asked for. Should
> be one of the #defines above. */
> apr_uint64_t info_kind;
>
> /* A prompt to display to the user (if necessary). */
> const char *prompt;
>
> /* If prompting user, whether to echo typing or not. */
> svn_boolean_t no_echo;
>
> /* The desired information, filled in by the client. */
> char *info;
>
> } svn_ra_get_info_t;
>
>... reordered ...
>
> /* Pull a list of information from the client.
>
> INFOS is a list of svn_ra_get_info_t structures; the client's
> responses will be returned in each structure's `info' field,
> allocated in POOL. */
> svn_error_t *(*get_informations) (apr_array_header_t *infos,
> void *info_baton,
> apr_pool_t *pool);
>
> /* Store auth info in the client.
>
> Assuming authentication was successful, ask the client to store
> each svn_ra_get_info_t in INFOS -- so that the info will be
> cached for next time. */
> svn_error_t *(*set_informations) (apr_array_header_t *infos,
> void *info_baton,
> apr_pool_t *pool);

This won't work...

1) The RA layer should not do anything with prompts or echo status. That is
   just "out of scope" for RA -- leave it to the callback function.

2) The RA layer should not fetch items as individual units. Consider the
   user/password situation in a GUI. The pair are fetched at the same time.
   The point here is that stuff is fetched as a semantic group, rather than
   "fetch A, then fetch B, then C".
   (and I dunno why you'd use an apr_array_header_t since the set of items
    is known in advance and static)

3) Saving information is similar: based on the semantic, different things
   are saved. You sure wouldn't want to save the password for that SSL key,
   but you would for a plain-text HTTP password.

Each "type" of authentication is going to have a way to get the needed
pieces, and to save the appropriate pieces.

This is why I suggested a per-auth-type vtable that had "authenticate" and
"save" in it. Each type can then do everything needed. Each per-type
authenticator can return the appropriate needed information to the RA layer.

>...
> /* -- Authentication Callbacks -- */
>
> /* A context the client may need for getting/setting auth info. */
> void *info_baton;

Keep this out of the structure. This kind of thing was in the original
authenticator stuff, and it was a pain in the ass to get rid of. It means
that people cannot use static structures for the vtables. And that just
means it is a real bitch to construct and pass these things around. Pass it
separately.

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