Can't get basic auth credentials without supplying a username

[mkincaid]

Which version of GCM Core are you using?

Git Credential Manager version 2.0.164-beta+1264f234c7 (Windows, .NET Framework 4.0.30319.42000)

(Can also reproduce on macOS)

Which Git host provider are you trying to connect to?

HTTP(S) basic authentication

Expected behavior

>git-credential-manager-core store
protocol=https
host=host.name
username=foo
password=bar

>git-credential-manager-core get
protocol=https
host=host.name

protocol=https
host=host.name
username=foo
password=bar

Actual behavior

>git-credential-manager-core get
protocol=https
host=host.name

Enter credentials for 'https://host.name/'

This case of needing to fill the username is very common. For example, the series of interactions with Git described above happens if the remote is defined as https://host.name/path.git (as opposed to https://[email protected]/path.git). That means that, in practice, GCM Core appears to the user not to be able save credentials for https remotes without username@ in the URI (actually, they do get saved just fine, but under a different key than the one that’s used to try to retrieve them the next time).

Possible resolutions

The quandary arises from the implicit design assumption that any get request carries enough information to generate a unique, stable credential key that can be directly retrieved from the store. In the case of basic authentication without knowledge of a username, that doesn't hold.

In GCM for Mac and Linux the targetURI is always constructed, i.e. both retrieved and saved, as protocol://host (never including the username). This implementation works, but removes some flexibility (e.g. the option to save credentials for different usernames on the same host and distinguish among them by specifying username@ in the remote URL).

In GCM for Windows, this case is handled by setting CREDUI_FLAGS_PERSIST, so that credui itself saves the credential with label git:https://hostname (independent of any invocation of git-credential-manager store that might follow). But that approach doesn't seem to generalize well: for example, on macOS, we don't invoke a system UI for collecting credentials at all, so there isn't an analogous flag.

Of course, we could still store the credential this way after collecting it from stdin. But that creates a leaky abstraction: git doesn't expect anything permanent to happen on a get, only a store, so we are kind of going behind its back. In practice, that seems to be a contributor to problems with zombie credentials.

Legacy wincred enumerates through the credentials in the store and checks each one to see if it matches the pieces of information it does have. It seems like that's the right approach here, but it requires extending the credential store interface to have something like a GetAll or Enumerate method. I'd like to submit a patch to implement this change soon, but wanted to document this first and see if the maintainers had any input.

[mjcheetham]

Hello @mkincaid! Thanks for opening this issue.

You've hit the nail on head here! We're looking at an overhaul in the credential storage and recall APIs we use to match similar to how wincred does, across all platforms, to fix this issue with the basic/generic auth as well as help fix the issue of using multiple user accounts with other providers, such as the GitHub Provider (see #160).

Watch this space for a change that'll introduce these changes 😁

[mjcheetham]

Hi @mkincaid! Update for you on this one, we've got a pre-release out now which should fix this issue with basic auth and requiring a username.

https://github.com/microsoft/Git-Credential-Manager-Core/releases/tag/v2.0.246-beta

It's set as a pre-release at the moment, so isn't available on Homebrew yet, and not yet bundled with Git for Windows.

[mjcheetham]

Closing this issue now that the a release is available with this fix.
https://github.com/microsoft/Git-Credential-Manager-Core/releases/tag/v2.0.252-beta

[bbezanson]

@mjcheetham I tried installing the update for Git for Windows the other day (the 2.0.252 beta) which should have the above fix listed.

In order for my credentials to work, I needed to add allowWindowsAuth = true to the configuration file. I know you said that is fixed for a future release: #194

But I wanted to get things working now.

With the above fix, I was able to enter my user id and password and get my git command to run. However, when I ran the command again I was also prompted for my user id and password -- so for me the above defect fix does not seem to work in the 2.0.252 beta.

We are using a locally hosted bitbucket server using our corporate LDAP for authentication. I ended up reverting to the older (now deprecated) credential manager.

[mjcheetham]

@bbezanson could you please raise a new issue with this problem, including output when you set the GCM_TRACE environment variable to 1? Thanks!