That'll teach me to first read the entire thread. Sorry.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 14 September 2001 04:43
> On Thu, Sep 13, 2001 at 05:06:25PM -0500, Ben Collins-Sussman wrote:
> >...
> > A. new RA vtable sequence: put back open(). [EASY]
> >
> > RA->open (URL, callback, [...])
>
> session_baton = RA->open()
>
> > ...callback can be a way of storing a tmp file in WC.
>
> A single callback, or maybe a vtable of callbacks.
>
> > authenticator = RA->get_authenticator(method)
> > session_baton = svn_client_authenticate(authenticator)
>
> No return value there. You authenticate the session_baton returned by
> RA->open.
>
> But see below: I don't think you even have RA->get_authenticator. Instead,
> you would have the vtable of callbacks, containing client-provided auth
> mechanisms.
Yes. +1.
> > [ B: pass RA session to client ]
>
> >...
> > C. Improve auth-method selection [EASY]
> >
> > -- auth-method as optional commandline switch
> >
> > Use a single switch that takes a string: e.g. --auth="ssl"
> >
> > -- else: keep trying all available methods until they all fail.
> > Cache info from one attempt to the next if possible.
>
> Probably not. It will be more than this. Consider the
> server-requests model.
> The server will be saying "give me <this>". In turn, RA would ask
> its caller
> for the requested information.
>
> IOW, RA is in control and is driving the selection. Not the
> client or WC or some other caller.
>
> To some extent, it is the client that is telling the RA what is available,
> and the RA negotiates between server-requests and client-provides. The
> client says "I have a function you can call to get a
> username/password." Or
> "I have a function to get a client-side cert."
Another option is installing default callbacks that simply print and
return failure.
> >...
> > D. Prompts [EASY]
> >
> > -- display the method being used
> >
> > -- display a 'default' username if available
> >
> > -- prompt callback should take an array of prompts
>
> Not sure what is going on here. This might be different based on the the
> above pull model.
>
> >
> > E. Push vs. Pull models. [HARD]
> >
> > The current system pre-emptively requests info, then "pushes" it
> > at the RA layer. This is odd, given that Apache typically makes
> > a challenge and then "pulls" the info. As a result, the info is
> > effectively being cached in the session_baton until Apache pulls
> > it from there.
>
> Yes.
>
> > So, it would be nice to switch the whole client/user-interface to
> > work with the "pull" model too.
>
> Not "too" but "only". The admin defines what the server wants for
> authn, and the client needs to meet that requirement.
Yes, it is strange to have a client 'push' info that the server doesn't
want.
> >...
> > F. Method negotiation? [HARD]
>
> Responded to elsewhere.
>
> Cheers,
> -g
Sander
---------------------------------------------------------------------
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