On Mon, 3 Nov 2008, Josef Wolf wrote:

> So here's a second try. Still not "production" quality, but this time doing
> the real change and without messing with the data structures.
>
> This version introduces CURLOPT_CREDENTIALFUNCTION to install the callback.
> There are no functional changes as long as the callback is not installed.

I think it would make sense to also provide a CURLOPT_CREDENTIALDATA in the
same sense all the other callbacks do, to provide a user pointer to the
callback.

> The failure of those test cases was to be expected, since the current stub
> provides only a fixed (and wrong) user/password combination. The question
> here is, how to deal with those test cases. I think they should be
> duplicated. The original versions of the test cases should be run without
> installing the callback, and the duplicates should be fixed to run properly
> with the installed callback.

I think so too. But I don't think you need to duplicate all the test cases
since the existing ones work pretty good to verify that the authentication
code actually works and you only need to add a set of tests that verify that
the callback concept works for authentication.

> But to make this work, the curl utility should be able to detect whether it
> is running a test case, whether to install the callback or not, and which
> credentials to provide. I guess there's no mechanism to handle this in test
> cases yet?

There is no such thing, but I would rather suggest that you'd write a little
test case for the 5xx series of tests which all are libcurl-using tests that
all have their own little test application that gets compiled and then runs.
You can then write a little snippet that uses libcurl and installs the
callback etc and use that to run the test(s).

> Then we come to one more question (which Daniel already mentioned at the
> very beginning): how should this be handled in the curl utility? Probably it
> would make sense to introduce a command line switch to activate the
> interactive callback.

Yes I agree. But you I can also see how the curl tool could use the existing
options to feed the callback data with if things match. Ie to use the new
callback option to offer new functionality (auth based on the actual realm in
the response header) and use the existing way to get that credential data. I
mean, in addition to the optional prompting at the time when the callback gets
called.

Anyway, the actual implementation in the curl tool is somewhat unimportant and
secondary to the libcurl change.

> After all, many people use curl in non-interactive scripts and we do not
> want to break those scripts by letting them sit and wait for interactive
> user input. Using a command line switch might also be the solution to the
> test case questions mentioned in the previous paragraph.

True...

> BTW: I can't seem to find a way for properly determine the realm.
> AFAICS, the realm is extracted only for Digest?

Yes, as Digest is the only auth type that really need realm for its
functionality there is no existing code that extracts it. This will have to be
added to make this work properly.

> Comments? Suggestions?

Two comments/thoughts:

A) A 401/407 response may indicate multiple authentication types. I'm not sure
    there is a guarantee that they will have the same realm. Thus it is of
    importance to keep track of only the one that is from the auth type of
    choice. I noticed your current approach at least doesn't alter how libcurl
    picks which auth to use when there are multiple ones to select from. (I'm
    not saying that really is needed either as unwanted auth types should not
    be asked for in the first place.)

B) Possibly a somewhat larger issue: what about the case when you use libcurl
    to get multiple pages from the same auth protected site that uses the same
    (or different) realms for the multiple resources your app requests? Are you
    then calling the callback on each occurance to let the applicaton do any
    possible caching of the realm to credential mapping? This is perhaps most
    notable in cases where redirects are used (with closed connections in
    between) since then the callback could in fact get called multiple times
    when just a single resource is requested!

-- 
  / daniel.haxx.se