[apologies if this appears twice; I tried posting through gmane, but it
seems to have been eaten, presumably due to the only-subscribers-may-post
On Sat, May 12, 2012 at 02:52:09PM +0200, Daniel Stenberg wrote:
> 3 - We try to get people to try it out. I will for example explicitly ask the
> git team for feedback since they've been wanting an API like this and it
> would be valuable to make sure we make something that suits them as well.
I took a look at what Joe published here:
and worked up a preliminary patch for git to handle the new interface:
It worked in some very basic tests I conducted, but I ran into a few
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.
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).
3. I like how the prior username and password are provided to the
callback so that I can mark them as rejected (e.g., in a password
store). But what is the best way to mark them as approved (i.e., to
say "yes this worked", and store it in a password store)? I can
wait until the request finishes successfully. But then I have to
correlate that request with the particular auth state that the
callback received. So when I see my request for
"http://one.example.com" finish, I have to remember that the when
the auth callback happened, I was actually hitting
"https://two.example.com" due to a redirect.
I guess I could remember the CURL* pointer that came into the auth
callback and correlate that with the completed request. Which is
kind of ugly. Or I suppose that I could put a per-handle "struct
credential" into the HTTP_AUTH_DATA pointer, fill it in during
the callback, and then "approve" it when the request completes. But
that makes it a bit harder for multiple handles to share the same
credential set (or maybe I just need to improve my credential data
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.
Just my two cents as a potential user of the new API.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2012-05-16