On Tue, 4 Nov 2008, Josef Wolf wrote:

>> 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.
>
> You mean to install the callback when --user or --proxy-user is supplied
> without a password? AFAICS, those are the only cases where current
> implementation would prompt for credentials. Changing any other use-case
> without a new option could break existing (non-interactive) scripts.

Yes, but I meant using the callback without prompting the user. I can easily
see how it can be useful to be able to:

   curl --user daniel:secret --realm backyard home.com

... and this will only send the credentials if the correct realm is asked for.
The callback enables this feature without the prompting being necessary. I can
of course also see how you may want to ask for the credentials in the
callback, but that would need a(nother) new option as already discussed.

> Then, there's the edge-case of http://user@host/. This case gives 401
> in the current implementation.

I don't understand. You mean "current" as in before your patch or after? And
401 simply implies that the credentials are wrong, surely that syntax doesn't
unconditionally and always provide wrong credentials? I thought it simply
picked an empty password.

> Dan stated this is by design. I am not sure at all about this use case.
> For sure, prompting would break existing scripts. OTOH, a 401 would break
> those scripts also.

If it already works this way then the broken scripts are already either fixed
or the effect is intended. Changing this behavior is then what will lead to
broken scripts.

> | The realm value
> | is a string, generally assigned by the origin server, which may have
> | additional semantics specific to the authentication scheme. Note that
> | there may be multiple challenges with the same auth-scheme but
> | different realms.
>
> I must admit, I don't really understand that last sentence. Does it
> mean something like
>
> WWW-Authenticate: Basic realm="My protected area"
> WWW-Authenticate: Basic realm="Company protected"
>
> would be legal in the _same_ response header? Which realm is to be
> presented to the user when prompting for the credentials, then?

Yes, I interpret it that way. In fact how else could it be meant?

And if it can be different within the same auth-scheme, I'm convinced it can
be different between different auth-schemes too...

I tested how ff3 deals with multiple realms for the same auth-scheme, and it
seems to first present the first in a prompt and if I cancel that I get to
enter name and password for the next one instead.

> Anyway, it looks like you're right, the scheme should probably be added to
> the tuple, because every challenge can have its own realm.

But what about multiple for the same auth-scheme then? Call the callback once
for each? There should probably be some magic return code for the callback to
signal back "bad realm" or something.

>> 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!
>
> Hmmm, I am not sure I understand the scenario you try to point out here.
> If we find the requested tuple in the cache, we can use the associated
> credentials. If we don't find them, we should ask the application for
> help. Am I missing something?

Not at all. I was just speculating on the effects of _not_ having that sort of
cache within libcurl.

-- 
  / daniel.haxx.se