Repository navigation
fix: keep git provider tokens out of clone URLs - #5619
Closed
Souvik-Cyclic wants to merge 1 commit into
Closed
Souvik-Cyclic wants to merge 1 commit into
Souvik-Cyclic wants to merge 1 commit into
Conversation
AminDhouib
added a commit
to DevinoSolutions/dokploy-community
that referenced
this pull request
Oct 12, 2026
fix: keep git provider tokens out of clone URLs (port of Dokploy#5619)
decryptedchaos
pushed a commit
to decryptedchaos/dokploy-community
that referenced
this pull request
Oct 22, 2026
Ports Dokploy#5619 (0d8bf3b). The GitHub, GitLab and Gitea providers cloned with the token in the URL, so git printed it while registering relative submodules and stored it in .git/config. Pass the token as a host-scoped Authorization header instead.
decryptedchaos
pushed a commit
to decryptedchaos/dokploy-community
that referenced
this pull request
Oct 22, 2026
…remotes Extends the header-based clone credentials from Dokploy#5619 to the paths the upstream change does not reach in this fork: - Bitbucket (API token and username/app password) now sends Basic credentials in a host-scoped http.extraHeader instead of the clone URL. - Preview head-ref checkouts (github/gitlab/gitea) add the header to the two fetches and the submodule update and register a credential-free origin, so the token is no longer stored in .git/config. - getGitBasicAuthConfig generalises the helper to any username/secret pair; getGitTokenAuthConfig keeps the oauth2 form. Tests cover each provider (plain and head-ref), compose and remote-server clones, a hostile password staying a single argument, and redaction of the header in command errors.
Merged
3 tasks done
Collaborator
|
This was already fixed. Thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR about?
The GitHub, GitLab and Gitea providers clone with the token in the URL (
https://oauth2:<token>@host/owner/repo.git). When Enable Submodules is on and.gitmodulesuses relative URLs, git resolves each submodule URL against that remote, so the submodule URL carries the token and git prints it while registering the submodule. The token ends up in every build log (#5618), and it is also stored in the cloned repo's.git/config.This keeps the clone URL clean and passes the token as an
Authorization: Basicheader scoped to the clone host (git -c http.<origin>/.extraHeader=...). It is the same header git already sends foroauth2:<token>@URLs, and the-csetting reaches the submodule clones, so private relative submodules keep working. Nothing after the clone needs the token in the remote URL.Verified with a local git server that requires auth and a repo with a private relative submodule: on
canarythe log containsSubmodule '...' (http://oauth2:<token>@...); with this change the clone and the submodule clone succeed for all three providers and the token appears neither in the output nor in.git/config. Also added tests for the generated clone commands.Checklist
Before submitting this PR, please make sure that:
canarybranch.Issues related (if applicable)
closes #5618
Screenshots (if applicable)
N/A
The PR appears safe to merge; no actionable issues were found.
Summary
The PR removes tokens from GitHub, GitLab, and Gitea clone URLs. It sends the same credentials through a host-scoped Git header instead.
Reviews (1) · Last reviewed commit: "fix: keep git provider tokens out of clo..." · Reviewed by Greptile