[PR #1448] Fix #387: Fix git clone auth by honoring configured git account username #28676

New Issue

GiteaMirror · 2026-07-13T14:31:03-05:00

GiteaMirror commented

2026-07-13 14:31:03 -05:00

📋 Pull Request Information

Original PR: https://github.com/moghtech/komodo/pull/1448
Author: @lukababu
Created: 5/27/2026
Status: 🔄 Open

Base: main ← Head: fix/git-account-username-in-clone-url

📝 Commits (1)

58def20 Parse username and token

📊 Changes

2 files changed (+58 additions, -4 deletions)

View changed files

📝 bin/core/src/helpers/mod.rs (+34 -3)
📝 bin/periphery/src/helpers.rs (+24 -1)

📄 Description

Closes #387

Why

Private repo clones can fail on providers that validate HTTP basic-auth usernames (for example GitLab deploy tokens, Bitbucket, and GitHub fine-grained PATs).
Komodo currently resolves a token but loses the configured account username before URL construction, so clone URLs fall back to token:<token>@.... That causes HTTP Basic: Access denied for providers that require a specific username.

What changed

Updated Core git credential resolution to return credentials in username:token form (while preserving existing token values that already contain : for backward compatibility).
Updated Periphery fallback credential resolution to do the same when Core does not provide a token.
Added comments documenting the auth flow and compatibility behavior.

Behavior

Before:

Clone URL often became https://token:<token>@<provider>/<repo>
After:
Clone URL uses configured account username:
- https://<configured-username>:<token>@<provider>/<repo>

Backward compatibility

Existing setups that already use the v1.19.2 workaround (token field manually set to username:token) continue to work unchanged.

Validation

cargo check -p komodo_core passes
cargo check -p komodo_periphery passes
cargo clippy -p komodo_core -p komodo_periphery --no-deps passes
Reproduced failing GitLab deploy-token clone case before patch
NEEDS TO BE DONE - Verify clone succeeds after patch with same provider/account config

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/moghtech/komodo/pull/1448 **Author:** [@lukababu](https://github.com/lukababu) **Created:** 5/27/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/git-account-username-in-clone-url` --- ### 📝 Commits (1) - [`58def20`](https://github.com/moghtech/komodo/commit/58def20886054c0b8fe951cc5262c25756ace847) Parse username and token ### 📊 Changes **2 files changed** (+58 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `bin/core/src/helpers/mod.rs` (+34 -3) 📝 `bin/periphery/src/helpers.rs` (+24 -1) </details> ### 📄 Description [Closes #387](https://github.com/moghtech/komodo/issues/387) ## Why Private repo clones can fail on providers that validate HTTP basic-auth usernames (for example GitLab deploy tokens, Bitbucket, and GitHub fine-grained PATs). Komodo currently resolves a token but loses the configured account username before URL construction, so clone URLs fall back to `token:<token>@...`. That causes `HTTP Basic: Access denied` for providers that require a specific username. ## What changed - Updated Core git credential resolution to return credentials in `username:token` form (while preserving existing `token` values that already contain `:` for backward compatibility). - Updated Periphery fallback credential resolution to do the same when Core does not provide a token. - Added comments documenting the auth flow and compatibility behavior. ## Behavior Before: - Clone URL often became `https://token:<token>@<provider>/<repo>` After: - Clone URL uses configured account username: - `https://<configured-username>:<token>@<provider>/<repo>` ## Backward compatibility - Existing setups that already use the v1.19.2 workaround (`token` field manually set to `username:token`) continue to work unchanged. ## Validation - `cargo check -p komodo_core` passes - `cargo check -p komodo_periphery` passes - `cargo clippy -p komodo_core -p komodo_periphery --no-deps` passes - Reproduced failing GitLab deploy-token clone case before patch - NEEDS TO BE DONE - Verify clone succeeds after patch with same provider/account config --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-07-13 14:31:03 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#28676