I've been trying to find a decent place for the proxy callbacks without any
major change to the svn_ra.h. Passing in the proxy information would either
have to be done by changing the parameters to the get_authenticator to accept
a proxy argument (which really doesn't make sense to the ra_local stuff) or to
add callback setting functions in the returned authenticator structure.
The sort of callbacks I'm thinking of would be:
typedef char *(*svn_ra_proxy_callback) (
svn_stringbuf_t *target_URL,
apr_pool_t *pool);
typedef char *(*svn_ra_userpass_callback) (
svn_stringbuf_t *target_URL,
char **username,
char **password,
apr_pool_t *pool);
The userpass callback could be used in many different cases. With a 'file'
prefix for the local disk and 'http' or 'https' for the remote proxy or
website. The callback could also be useful for passwords that have changed or
been mistyped. The application could try the website and if a 407 is returned
the callback could be queried again.
The actual connection code would have to be moved to the 'authenticate'
function as on many proxied networks you would not have access to DNS. I'm
not really happy when the proxy settings going inside the authenticator
structure but don't really seen another place for them at the moment. Have I
missed something?
thanks,
- Dale Thatcher
On Mon, Sep 17, 2001 at 07:44:34AM -0500, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>
>
> > Should have posted the header before rewriting :-)
>
> No worries. I'm used to rewriting and rewriting. :-)
>
>
> > 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.
>
> So in other words, even though RA is pulling info now, you're saying
> we *still* need to create specific structures for specific protocols?
> Are you sure this isn't being overly strict?
>
> Hmmm. Thinking about it, I suppose that even the "username" object
> can't be shared between protocols. When ra_local pulls a username,
> the client should return the process owner. But when ra_foo pulls a
> username, it may be trying to get it along with *all* auth info from
> some random file in ~.
>
> You make sense, will rewrite. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.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