Jeff King <peff@xxxxxxxx> writes: > On Sun, Jun 17, 2018 at 01:37:24PM +0200, Johannes Schindelin wrote: > >> > If it's just a custom Authorization header, we should be able to support >> > it with existing curl versions without _too_ much effort. >> >> Indeed. Because it is already implemented: >> >> git -c http.extraheader="Authorization: Bearer ..." ... >> >> To make this a *little* safer, you can use http.<URL>.extraheader. > > Yeah, that will work for some cases. A few places it might not: > > - some people may want to provide this only in response to a 401 > > - some tokens may need to be refreshed, which would require interacting > with a credential helper to do the rest of the oauth conversation > > - there's no good way to hide your token in secure storage (versus > sticking it on the command-line or in a config file). And all of these three are what you get for free by building on the credential helper framework, after extending it a bit so that the filled credential structure can tell the http code to show it to the other side as a bearer token, not a password or password hash. The helper is asked to supply the auth material only after 401, which covers both the first and the second points, and then keeping the auth material in-core (e.g. cache--daemon) would be more secure which covers the third point. Am I following you correctly? Thanks.
