Repository navigation
GitLab: Ignore username from Git credential input when looking up and generating credentials #2270
Description
Version
2.7.0.0
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
Expected Behavior
The GitLab provider should:
- Completely ignore the username from Git's credential input with OAuth
Rationale
- Using the input username can cause incorrect credential lookups and confusing authentication prompts
Actual behavior
Current Behavior
When Git passes a username in the credential request (e.g., username=test when remote.origin.url=https://test@repo.git), the GitLab provider:
- User runs
git pull - GCM checks for token for user
test- token is missing (not in cache, that's OK) - GCM asks user to login using browser
- GCM Stores token in cache with user
oauth(nottest) git pullis successful- User runs
git pullagain - GCM checks for token for user
test- token is not found due to invalid user! - GCM asks user again to login using browser
Logs
No response
Activity
tjuchniewicz commentedon Feb 20, 2026
Simple workaround is to remove user name from Git url. Not sure if it's worth to fix this issue. Maybe just add more logging to easily debug such issue.
mjcheetham commentedon Mar 12, 2026
Hello! This is expected behaviour. Git credential helpers should respect the username field when passed by Git. You'll also find this the case with the contrib helpers such as
wincredorosxkeychain.Is there a reason why you're including a username (that is not the correct user) in the remote URL?
tjuchniewicz commentedon Mar 19, 2026
We migrated from the legacy repository to GitLab.
In the legacy setup, users had to include a username in the repository URL. During migration, some users copied and pasted the old URL (changing host part only), not realizing that the embedded username is no longer valid in GitLab.
If changing this behavior is not feasible, we should add trace-level logging to make this issue easier to diagnose.
In my case, I had to add custom logs to the GCM source code, then compile and distribute a custom GCM build to identify the root cause.
But currently credential helper does it only partially, when storing token in cache, username is ignored and
oauthis always used as username.elieux commentedon Jun 29, 2026
I checked the credentials saved for different providers and GitLab seems to be the only one totally ignoring the requested username when saving ("d..." in the screenshot is my username). To be clear, I'm using the correct username for the account that I'm using to log in through the browser.
I also believe the use case for including usernames should be fairly obvious – I have both a personal account and a work account with a provider and some remotes should use one and some should use the other. Specifying the username in the remote URL has always been the way to do that, I think.
becm commentedon Jul 4, 2026
@elieux code for GitLab is locked to
oauth2for historic reasons.They actually checked the username value in
Basicauth at some point in the past.I agree that it's better to adapt naming/lookup with multi-user support (as in other providers) instead of adding another opaque special condition to the
GitLabcode path.becm commentedon Jul 4, 2026
As a mitigation for the multiple accounts per URL, it's still possible to use a credential.namespace.
A fix for the other account distinction option in the GitLab provider should be a simple matter of copy&paste (and test).Sadly, getting rid of the
oauth2account name is not so trivial;GitLab provider distinguishes authentication modes by the account name.
→ Candidate for local expiry detection of structured token (#1837), so username restriction can be removed.Token content query not an option, GitLab also uses an opaque value.
becm commentedon Jul 4, 2026
@mjcheetham the username should be part of the stored credential, but is replaced/ignored in GitLab OAuth2 case.
The GitLab provider misuses the account field for credential type metadata (trigger token expiry check).
So it's in direct violation of the described behavior.