[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
 setting]

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:

  https://github.com/JoeNotCharles/curl/commits/authcallback_api2_squashed

and worked up a preliminary patch for git to handle the new interface:

  https://github.com/peff/git/commit/83323576a9a0d07b5529fa3eb3be1810789cae49

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.

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

     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.

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