On Wed, Nov 05, 2008 at 11:34:22PM +0100, Daniel Stenberg wrote:
> On Tue, 4 Nov 2008, Josef Wolf wrote:

> >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.

Ah, OK.

> 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.

Maybe --interactive or something?

> >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.

It picks an empty password and returns a 401 if the server wants a
non-empty password. I mean, it is somewhat inconsistent to prompt
when --user omits the password and not to prompt when url-specification
omits the password.

> >| 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?

It seems to be somewhat inconsistent with the beginning of the same
paragraph.

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

Yes, that would be the consequence.

> 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.

The cache/callback could be handled in the same way. But multiple
challenges with the same auth-scheme should be implemented, then.

> >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.

Why not call them in turn until one succeeds or no more realms are left?
something like

   foreach realm (realms) {
     if (get_credentials (realm)) return credentials;
   }
   return failure

> >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.

OK.
Received on 2008-11-06