Re: Failing to push to a repository erases authentication helper credentials

On Mon, Jun 30, 2025 at 06:29:46PM +0000, brian m. carlson wrote:

On 2025-06-30 at 15:09:06, Michal Suchánek wrote:

quoted

On Mon, Jun 30, 2025 at 02:31:15PM +0000, brian m. carlson wrote:

quoted

It is in fact desirable because otherwise the user continues to attempt
to use the bad credentials and then can never again authenticate
successfully, since they are never again prompted for credentials.

My proglem is that the credentials are actually valid, only the
operation is not. The current behavior erases valid credentials.

Then the server needs to return a 403 or 404 and not a 401.  A 401
prompts Git to expire credentials and a 403 or 404 does not.  Only the
server knows whether the credentials are actually valid for some access
or not at all.

RFC 9110 § 15.5.2 says this:

    The 401 (Unauthorized) status code indicates that the request has
    not been applied because it lacks valid authentication credentials
    for the target resource.

and § 15.5.4 says this:

    The 403 (Forbidden) status code indicates that the server understood
    the request but refuses to fulfill it.
    […]
    If authentication credentials were provided in the request, the
    server considers them insufficient to grant access. The client
    SHOULD NOT automatically repeat the request with the same
    credentials. The client MAY repeat the request with new or different
    credentials.
    […]
    An origin server that wishes to "hide" the current existence of a
    forbidden target resource MAY instead respond with a status code of
    404 (Not Found).

So the server is incorrect in returning a 401 in this case if the
credentials are actually valid for a different operation on the same
resource.

Is there any way to see what the server is returning?

As the repository uses SSL capturing the communication with a proxy
would be challenging.

Thanks

Michal