GitHub Enterprise redirects to `localhost:80` instead of `127.0.0.1:60167`

[cliffchapmanrbx]

Version

2.2.1

Operating system

Windows

OS version or distribution

Windows 11

Git hosting provider(s)

GitHub Enterprise Server

Other hosting provider

GitHub Enterprise Server 3.8.2

(Azure DevOps only) What format is your remote URL?

None

Can you access the remote repository directly in the browser?

Yes, I can access the repository

Expected behavior

1. User clears their authentication settings in Windows Credential Manager (due to this issue).
2. User runs any git command that requires auth to our GHES instance.
3. User receives the expected "Sign in with Browser" popup and enters our GHES instance information, clicking the link.
4. The link takes the user through the OAuth operation and the user is signed in.

Actual behavior

On step 2 the initial GET URL will look like

GET https://OUR_GHES_SERVER_URL/login/oauth/authorize?client_id=0120e057bd645470c1ed&code_challenge=2NKS...&code_challenge_method=S256&redirect_uri=http://127.0.0.1:60167/&response_type=code&scope=repo gist workflow&state=36BUNCHOALPHANUMERICS9dd

Note the redirect URL of http://127.0.0.1:60167 as described in this change. The server will then respond with

302 Found
Location: http://localhost/?error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application.&error_uri=https%3A%2F%2Fdocs.github.com%2Fenterprise-server%403.8%2Fapps%2Fmanaging-oauth-apps%2Ftroubleshooting-authorization-request-errors%2F%23redirect-uri-mismatch&state=36BUNCHOALPHANUMERICS9dd

The user is unable to log in using OAuth.

Logs

Our current workaround for this is to suggest Log in with Code instead.

We are currently working to correlate affected users with possible machine configuration issues (many of these folks are web developers) that may be altering local URLs. This issue began this week as folks are updating to the latest version of Git for Windows.

Running diagnose and GCM_TRACE=1 did not reveal interesting information, just the tool correctly determining the GHE version and the Pat, OAuth schemes.

[cliffchapmanrbx]

Ah, interesting, in that linked change ticket Mislav indicates magic was done to make this work for GitHub CLI.

Going back to the original topic: in GitHub CLI, which also used to authorize over OAuth web application flow, we've migrated from http://localhost callback to http://127.0.0.1 in a way that's backwards-compatible, using the same OAuth app. This relied on a feature that's not public.

Perhaps this magic was not repeated on GitHub Enterprise Server for Git Credential Manager?

[mjcheetham]

Hello!

The issue is that the GHES instance has not been updated to register the new IP-loopback redirect URI, but GCM on the client-side is expecting it to have been updated.

We must continue to support the previous localhost-based redirect URI for older GHES instances.

A workaround to this issue for now is to set the following Git config setting, or the environment variable GCM_DEV_GITHUB_REDIRECTURI to http://localhost/:

git config --global credential.gitHubDevRedirectUri "http://localhost/"

Note that the trailing slash after localhost is important to keep.

[mjcheetham]

We've merged in a fix for this issue to the default branch, and will be available in the next release.

A hotfix release is planned imminently.

[cliffchapmanrbx]

Fantastic! Will be checking in this week for updates we can relay to our company.