On Tue, Jun 19, 2018 at 02:36:50PM +0200, Christian Halstrick wrote:
> What is not clear to me is how we can make use of the servers initial
> response in order control which credential helper to call and how to
> transport the credentials.
I don't think we'd ever decide _which_ credential helper to call; we
always call all of them, in order, and then quit when we have sufficient
credentials to continue.
But potentially we could feed some extra information to each helper and
let it decide what to do.
> Imagine we try to clone over http. The initial request sent to the
> server may not contain a "Authorization: ..." header and the server
> responds with Unauthorized. But the server response contains hints
> like a "WWW-Authenticate: Basic realm=..." line or a
> "WWW-Authenticate: Bearer realm=..." line which helps choosing the
> authentication scheme used next. Maybe the server even responds with
> both lines telling I would accept BASIC or BEARER.
So for this example, yeah, I think it might make sense to feed the
credential helper extra context like "authtype=basic" or similar. Most
helpers would ignore it, but smart ones could make a decision based on
it.
And then the response could contain a similar "authtype" key in the
response.
> I can imagine that we want libcurl to deal with that decisions. But
> even then. How do we make sure the our credential helpers can act
> return either user/password or bearer tokens based on the server
> response? If credential helper would have access to the servers
> response (or only relevant parts of it?) it could decide whether to
> feel responsible for that server or not and what data to return.
>
> And if credential helper could optionally give metadata about the kind
> credential they offer (e.g. "I return user/password" or "I return a
> bearer token") then core code could know where to transport this data.
> E.g. in a "Authorization: Basic ..." or a "Authorization: Bearer ..."
> field.
Yep, I think that all matches my general line of thinking. It would help
if we had some concrete cases. In particular, it's unclear to me if:
1. A config option to say "treat password as a bearer token" would be
enough.
2. We'd need the credential helper to say "I'm giving you a token"
versus "I'm giving you a password".
3. We might need _both_ (1) and (2), because some servers would be
fine with (1) and it lets them Just Work with credential helpers
that are unaware of bearer tokens in the first place.
I suspect the answer is (3), but I'd probably delay working on (2) until
I saw a situation that really needed it. :)
But I think we're on the same page, so if you're looking into or
developing more concrete cases, those answers should become more clear.
-Peff
