> From: curl-library-bounces_at_cool.haxx.se [curl-library-bounces_at_cool.haxx.se] on
> behalf of Jeff King [peff_at_peff.net]
> Sent: Tuesday, May 15, 2012 11:19 PM
> To: libcurl development
> Subject: Re: introduced an auth callback
>
> It worked in some very basic tests I conducted, but I ran into a few
> issues:
>
> 1. I had to turn off CURLOPT_FAILONERROR to trigger the new callback
> code. I'm not sure why git uses FAILONERROR in the first place, or
> what changes we need to adapt to this, so it may not be a big deal.
> But it seems like curl should not consider a request to end in
> error until the callback sends a CURLAUTHE_CANCEL.

Good catch! I'll look into that.

> 2. When the auth type is CURLAUTH_TYPE_PROXY, the URL field still
> contains the destination server's URL. But what I really want to
> know is the proxy's URL, since that is where the authentication
> credentials are going (other callers might _also_ want to see the
> actual destination URL, but git does not care in this case).

Also a good catch. But is the url really helpful for proxy auth? First of all the proxy address and port isn't really a url, just an address, and second it doesn't change due to redirects like the url does. So presumably whoever set the proxy address still knows what it is. Would it be ok for the url to be NULL for CURLAUTH_TYPE_PROXY? (I ask this mainly because I'm not sure where to look up the proxy address from when filling in the info struct, but also partly because it feels a bit impure to be putting the address into "url" when it's not actually a url.)

> The simplest thing for me would be if CURL called an auth callback
> (either a separate one, or the same one with an extra flag) to say
> "yes, I made a successful request to URL X with username Y and
> password Z". Maybe that is too ugly to go into curl itself, though.
> That doesn't necessarily mean that your auth info is good, only
> that the server did not complain (for all the client knows, the
> server did not need any auth at all). On the other hand, it is
> probably the best guess a client can make about whether or not the
> credential worked. I assume it's what browsers do when storing
> passwords, but I haven't checked.

Well, curl knows what type of auth it ended up sending, so in theory it can call the callback with that info when it succeeds. This would be a good thing to put into the library because the embedder doesn't have that info easily. I don't know exactly what to change in curl to make this happen off the top of my head, though, so it might not be trivial. And I don't have a lot of time in my schedule to look into it.

How about adding a bool "succeeded" parameter to the info struct, and just leaving it as false for now? Someone else can implement the true case in a followup.

Joe
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-16