curl-library
Re: CURLOPT_PASSWDFUNCTION
Date: Tue, 5 Aug 2003 01:28:18 +0200 (CEST)
On Mon, 4 Aug 2003, Joerg Mueller-Tolk wrote:
> As far as I am aware of, you can specify a password with the password
> callback during curl_easy_perfom() if one is needed.
Yeps.
> But the username has to be set before by a call to curl_easy_setopt(). In
> case of a HTTP operation, I might not know whether some (proxy)
> authentification is need and do not want to ask the user for its name (and
> domain) needlessly.
I can understand this completely. I do have quite a few thoughts on your
suggestion though, as you'll see below!
> Up to now, I wait for a HTTP 407 or "Proxy requires authentification"
> error, ask the user for both name and password and do a start over.
Yeah, that works somewhat for proxy authentication, and you can wait for 401
to deal with host authentication.
> What do you think of a new option CURLOPT_AUTHFUNCTION with a callback
> similar to
>
> int my_auth(
> void *client,
> char *prompt,
> char *domain_user_passwd_buffer,
> int domain_user_passwd_buflen);
>
> The callback could be called if no CURLOPT_PASSWDFUNCTION is specified and
> data is needed. The format of domain_user_passwd_buffer could be
> "domain\\user:passwd" or just "user:passwd".
(I would probably suggest then that the domain_user_passwd returned should be
url-encoded so that names and passwords or whatever can contain colons or
backslashes if someone would want that.)
What would 'prompt' do?
Wouldn't this be usable for normal host authentication as well? If so, there
should be some kind of info on whether this is a proxy or a remote host that
needs the info.
If you'd do a browser or something, you'd want the 'realm' part of the
(WWW|Proxy)-Authenticate: headers. Shouldn't that somehow be passed in too if
available?
I'm also strongly in favour of passing on the easy handle for the particular
connection to the callback, to allow queries to be made to libcurl from within
the callback (at least in a future libcurl that may be able to return more
interesting info on direct questions), such as "current URL", "auth scheme
used", "current host name" or whatever might occur one day.
Would this be called for FTP as well?
Perhaps it would be easier if you started out by telling why your current
"wait for 407" isn't good enough? After all, that 407 round-trip is still
gonna be made even if this system were added.
-- Daniel Stenberg -- curl: been grokking URLs since 1998 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01Received on 2003-08-05