On Wed, 22 Oct 2008, Josef Wolf wrote:

> I have to correct myself here. The signature should look something
> like:
>
> int curl_get_credentials (char *user, char *passwd, /* return values */
> const char *realm, const char *url,
> int isproxy)

You'd also want a custom user pointer (for passing on local contexts) and
possibly a CURL *. I wonder if a auth type (Basic, Digest, NTLM etc) would be
wanted as well.

> maybe with additional parameters telling the size of the buffers for the
> returned values.

That too, otherwise it's like begging for overflows.

> For sure, this can be done without a callback. But I think the callback
> solution would be the better solution for several reasons:
>
> 1. It separates protocol handling (which, IMHO, belongs into the lib)
> from user-handling (which clearly belongs into the application).

IMHO, that's already separated and adding of a callback doesn't really change
this.

> 2. I expect the callback method to avoid code duplication on three levels:

Yes, it just might and those are some good reasons. Although most of it could
be solved without adding a callback if just the right info is returned or is
readable after the return.

But in my experience applications in general don't have general 40[17]
response handlers. Most apps already know when they need auth and they already
set the requested type(s) and they provide name and password. I think that's
the primary reason why not more people have asked for support of something
like this.

> c. I guess even some code from CURLOPT_FOLLOWLOCATION could be
> reused.
> After all, the overall handling for both situations is
> identical: repeat the request with slightly modified parameters.
> The only difference is that in case of 401/407, the additional
> parameters need to be retrieved from the application instead
> of the response header.
> I don't see the point in handling one situation within the
> library but requiring the application to handle the other
> (almost identical) situation by itself.

libcurl already has lots of support and code for 401/407 handling (and yes it
is similar to the redirect following in large parts) so that's now what would
be needed to get introduced.

> Actually, I have stolen the callback idea from LWP::UserAgent. It
> really makes credential handling a trivial no-brainer from the
> application point of view.

I don't think it is hard in libcurl's case either the way it is most commonly
used. But yes, when making a general purpose "browser-style" approch it is a
bit awkward and this kind of callback makes it easier for the app.

> 5. I guess, there might be even the opportunity to simplify libcurl
> by decoupling current user/password handling from the core library.

I don't quite see what you mean by this. How is this decoupling anything from
the core library? To me, it's just a (different) way to get user and password
passed into the lib.

In summary: I'm not entirely against the idea. It'll of course take a chunk
of code to get this working nicely.

-- 
  / daniel.haxx.se