Re: Remembering which http remotes require authentication

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 12, 2023, 21:21 UTC
Message-ID: <ZIeMcyloOiyAJ8ak@tapette.crustytoothpaste.net>
In-Reply-To: <CAGJzqsnkH_dtv-CGsSFJ8K0kXKBf1+QQqy=MEw-Vq9XaEqr=AQ@mail.gmail.com>

On 2023-06-12 at 06:47:19, M Hickford wrote:

Show 18 quoted lines

> Most http remotes require authentication to push. Private repositories
> also require authentication to fetch.
> 
> If I understand correctly, http_request_reauth [1] first makes an
> unauthenticated http request. If this fails with error 401
> Unauthorized, then Git retries with authentication. This avoids
> potentially expensive `credential fill` unless necessary. (`credential
> fill` may be fast, slow or even require user input)
> 
> Could Git remember which remotes require authentication for which
> operations? On high-latency networks such as 3G or satellite
> connections [2], skipping a doomed unauthenticated request could
> potentially halve the time taken for some commands.
> 
> A complication: if a repository changed from private to public, Git
> would continue to authenticate when no longer necessary. A solution
> could be to remember to skip the unauthenticated request for a limited
> amount of time, or a maximum number of requests, before rechecking.

What I would rather see instead is a way to indicate to Git that it should always authenticate via a config option (probably something like `http.*.alwaysAuth`). I think this would work for your use case, but it would also work for things like giving authenticated users higher rate limits for public repositories.

I intend to add this feature at some point relatively soon, but I need to sneak in a feature first to specify the authentication scheme as part of the credential protocol, since we won't have it as part of the HTTP 401 response.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA