mirror of
https://github.com/moghtech/komodo.git
synced 2026-05-06 08:55:40 -05:00
[GH-ISSUE #387] Git Clone Repo tries to authenticate with "token" and "<TOKEN>" #2147
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/komodo#2147
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marrobHD on GitHub (Mar 29, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/387
The feature "Git Clone Repo" tries to authenticate with "token" and "<TOKEN>" instead of using the specified user and password.
The komodo error shows command:
git clone https://token:<TOKEN>@gitserver.de/ORG/docker-komodo /etc/komodo/repos/<TOKEN> -b mainGitea shows error:
routers/web/web.go:124:func7() [E] Failed to verify user: user does not exist [uid: 0, name: token]Using
latesttag.@TheNickOfTime commented on GitHub (Apr 3, 2025):
I am having this issue as well. Basically all git operations fail. Using the previous version has no issues.
@mbecker20 commented on GitHub (Apr 3, 2025):
This works with git access tokens, are you able to create an access token on your git provider and use that as the token?
@TheNickOfTime commented on GitHub (Apr 4, 2025):
I was using an access token - I'm not sure what my issue was because it isn't happening anymore. Previously I was getting an error on cloning a repo along the lines of
Failed to clone repo - too many argumentseven though the git clone command it was reporting it was issuing worked fine if I copy and pasted it into my local environment. Originally going back to the last 1.16.x release fixed things for me, but I just tried a fresh install with 1.17.0 to reproduce the issue I was having and everything is working fine so far. 🤷P.S. I appreciate your work on this project - having my container stacks deploy and update when I merge PRs from renovate is basically black magic 🙏
@TheTrojan007 commented on GitHub (Apr 9, 2025):
I had the same issue as @marrobHD. Also using the latest tag (v1.17.0).
The apllication tried to clone the repo with "git clone https://token:<TOKEN>@gitea.servername.com/..."
During diagnosing the issues the "<TOKEN>" part actually disappeared completely and now tries to authenticate without any token: "git clone https://token:@gitea.servername.com/..."
I am using a git account added manually in the Settings>Providers section with a working token (I tried "git clone https://token:actualToken@gitea.servername.com/..." locally and it worked)
@Zylatis commented on GitHub (May 5, 2025):
Same issue as above
@HumnResources commented on GitHub (May 6, 2025):
Bump. Confirm same issue. Managed to resolve it once before by reinstalling but that was after multiple attempts/versions. Double checked the token is valid and has access, just appears to not be passed through to the command. In both cases, my git auth failed after a few days of no issues, with no changes to server config.
@rVox-Dei commented on GitHub (May 10, 2025):
Bumping. Same issue. Running a self-hosted Gitlab instance and I've tried Deploy Keys, Deploy Tokens and Personal Access tokens with the same failing to authenticate response as above.
@ravxen commented on GitHub (May 16, 2025):
Bump. I got the same issue.
Funny thing is, that the personal access token from gitlab.com works, from my selfhosted gitlab not.
@lu1as commented on GitHub (May 16, 2025):
I was able to use a project access token (Role: Reporter, Scopes: read_repository) on my self-hosted GitLab instance as a workaround for now.
@ravxen commented on GitHub (May 16, 2025):
What did you put in as a username?
@lu1as commented on GitHub (May 16, 2025):
The name of the token. But I guess GitLab does not check the username for these types of tokens, that's why it works.
@tullisar commented on GitHub (May 22, 2025):
I can confirm this happens using Atlassian Bitbucket. Personal access tokens generated for a user use the URL scheme :, and if you use the wrong username (in this case "token" gets used), Bitbucket denies the request. The username selected in the repository configuration isn't used at all for the clone command.
I also noticed (similar to others) that the token disappears entirely with certain characters. Specifically in my case a token had '/' characters in it. I escaped them in the Komodo configuration, which resulted in the token being passed in the command but I think the characters might need to be URL encoded. When I regenerated my token for one that didn't have a / character that worked (minus the username issue mentioned previously).
@Netruitus commented on GitHub (Jun 8, 2025):
I think it's quite related.
In my case not only token is the problem, but also for some reason Github tries to pull through http:
git clone http://token:<TOKEN>@github.com/Netruitus/project-c/repo-cache/github.com/Netruitus-project-c/main/latest -b mainToken and repo were checked, I could pull everything locally. I refreshed the config many times, it stays http. Re-created the stack too, didn't help.
@NickMckloski commented on GitHub (Aug 7, 2025):
A work around to use a deploy token from gitlab is to just give it the username "token". Other access tokens from github work regardless of the username, this seems to just be an issue with certain providers who are strictly checking the username.
@tnelson-doghouse commented on GitHub (Aug 14, 2025):
For Bitbucket, the username needs to be "x-token-auth". So I guess we're stuck.
@tnelson-doghouse commented on GitHub (Aug 14, 2025):
For those wondering, the faulty code is at
118ae9b92c/client/core/rs/src/entities/mod.rs (L504).If the line were changed from
Some(token) => format!("token:{token}@"),...to...
Some(token) => format!("{username}:{token}@"),... then that would probably work.
Until that happens, Komodo is useless for BiBucket users.
HTH,
@tomazurro commented on GitHub (Aug 20, 2025):
As a workaround on self hosted git repositories one may define basic authentication and a user named token using the same password as was set as token for the user in komodo, since komodo requests urls of the form
https://token:<KOMODE_CHOSEN_USER_TOKEN>@git.domain.tld....
@mbecker20 commented on GitHub (Sep 1, 2025):
Hi, v1.19.2 is now out, and as per the release notes, Git Providers such as Bitbucket with particular
<token>:<access_token>patterns in order to authenticate can now can include that part in with the Access Token. If not explicitly prefixed using:, it will default totoken:<ACCESS_TOKEN>, making this change non-breaking for existing users.Before closing, may I ask if there are any cases here which this feature does not fix?
@matthieu-paturot commented on GitHub (Oct 15, 2025):
Hi,
I found a workaround for Bitbucket, in the "Token" field, I set :. Not sexy but it works.
@AndreKR commented on GitHub (Oct 26, 2025):
Ok, with the username in the Token field, it now works with a GitLab deploy token. If the username goes into the "Token" field, what is the "Username"? An identifier for the account?
@proton1k commented on GitHub (Jan 5, 2026):
Thanks @mbecker20 , your trick works for bitbucket.org!
@mrVragec commented on GitHub (Apr 4, 2026):
Worked for me in github, just take care that token used in Komodo has correct permissions.