Constant popups to authenticate HTTP(S) access to the remote repository

[claell]

Version

2.4.1

Operating system

Windows

OS version or distribution

Windows 11

Git hosting provider(s)

GitLab

Other hosting provider

No response

(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

When opening VS Code with nested git submodules, the credential manager manages authentication with stored credentials.

Actual behavior

Coming from https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1083. I suspected that extension to cause the problem, but apparently, it is caused by the git extension. Now, I got transferred from microsoft/vscode#205707 to here, hopefully this is the right place.

For such setup, the credential manager opens many popups asking me to authenticate. This is not wanted and might be related to having several nested submodules in the project (all typically hosted on the same GitLab server).

Steps to Reproduce:

• Have a clean Windows installation.
• Install VS Code
• Install the GitLab extension (probably not needed, as the issue still occurs after uninstalling that extension)
• Install git for Windows (select VS Code as git's default editor; might not be relevant)
• Clone one or two private projects from gitlab.com with git submodules in them (not sure whether the submodules are relevant) - I just used the "Open in your IDE" option "Visual Studio Code (HTTPS)" on the GitLab project website.
• Initialize the submodules with git submodule update --init --recursive (not sure if relevant)
• At some point authenticate with GitLab through the Git Credentials Manager popup window (select "Sign in with your browser")
• Wait a bit, play around with revoking the application access at https://gitlab.com/-/user_settings/applications. Possibly also reauthenticate from other machines. Close and reopen the VS Code projects on the clean installation machine.

Logs

No response

[jlcummings]

Version

git --version

2.39.1.windows.1

Operating system

Windows

OS version or distribution

10 Enterprise 22H2 2009 19045.4239

Git hosting provider(s)

Self-Hosted GitLab 14.9.5

Other hosting provider

NA

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

NA

Can you access the remote repository directly in the browser?

Yes, I can access the repository; and the command line; and from apps using their bundled clients.

I am having what I think is a similar situation. It does not seem to matter which client or version of the client, but perhaps lies with an Edge update or a Windows credential store change from a recent corporate update.

I haven't purposefully changed my configuration nor has the Gitlab instance in question changed that I can tell, but it is is in a corporate environment so some infrastructure and machine updates are beyond my control and I am not always notified of changes, but while it worked a certain way for months, I came back after last weekend, and my machine had changed. Something, somewhere changed the behavior or system interaction of git, the gitlab driver(?), git-credential-manager, or wincred/whatever they are calling the native windows credential store now. I have rolled back my winget remove Git.Git and winget install Git.Git --version ... from 2.44 to 2.39 and various versions in between, so I am not convinced it is entirely a Git issue per se, but rather how Git for Windows interacts with the underlying system for doing Oauth, with in particular Gitlab, because that's what I use in corporate where my immediate issue lies.

Before I would only rarely have to affirm credentials through the credential manager, but now every git operation appears to require affirmation (clicking the 'Sign in with your browser' button of the popup), as if the refresh token of the auth process is not being considered, accessed, or it is and it is not being correctly generated. I verified in the windows credential manager that both the initial, base credentials and refresh token appear to be updated each time I use or affirm. It does not appear to be a timing/expiration issue per se, again, because every git operation requires its own affirmation, unless expiration is set to zero somewhere that isn't obvious.

I have run a few debugging/logging functions that I have found scattered about, and tried various modifications and base configurations, and as a niave user, I haven't seen anything stand out as broken, but I also haven't seen how to trace the Oauth flow either, and that is where I am feeling my (and my entire team's) issue lies.

[claell]

Interesting, this problem seems to also affect other users (which will hopefully make fixing it easier).

Are you using git submodules, by any chance? I suspected this to trigger the issue, but am not really sure. So if you run into this without (ever) using git submodules, that would be an interesting data point.

BTW: I think, it started occurring for me already several months ago.

[jlcummings]

Interesting, this problem seems to also affect other users (which will hopefully make fixing it easier).

Are you using git submodules, by any chance? I suspected this to trigger the issue, but am not really sure. So if you run into this without (ever) using git submodules, that would be an interesting data point.

BTW: I think, it started occurring for me already several months ago.

Not using git submodules.

[Deracination]

Seeing the same problem since switching to Win11. No problems on Win10.

GCM --version: 2.4.1
GitForWindows: 2.44.0

connecting to bitbucket
no submodules
using LFS

Windows Credential Manager shows the credentials are being stored but git always displays the credential manager prompt and requires the token to be entered and updates the stored credentials. Deleting and/or editing the credentials in credential manager makes no difference.