Access tokens broken if embedded in URL

How to Use GitLab
1

I’m trying to use deploy tokens to clone an internal repo from our self-hosted GitLab instance (gitlab-ee-16.9.2-ee.0.el9.x86_64), and I can’t get it to successfully clone the repo if the token is embedded in the URL: git clone https://<username>:<token>@gitlab.example.com/repo.git

However, if I only supply the username and paste the token in the password prompt, the repo will clone without issue:

git clone https://<username>@gitlab.example.com/repo.git
Cloning into 'repo'...
Password for 'https://gitlab.example.com': <token>
# Successful clone

The same thing happens regardless if I use personal, project, or deploy tokens. Is there something I might have missed?

Kind regards.

2

This might work

git clone https://oauth2:<token>@gitlab.example.com/repo.git
3

Unfortunately, that did not work. Also, it seems like the username is only relevant for deploy tokens. When I tried this with personal/project access tokens, I could use any username with the token.

4

The docs do say that any non-blank value can be used as the username with personal/project access tokens, while a specific username is generated (or can be specified) for deploy tokens.

I can’t find any conclusive information on it, but I suspect the Git CLI may have dropped support for passwords in the URL, much like browsers started doing. At least the official docs on Git URLs don’t make any mention of passwords. Then again, that page doesn’t even show the username as an option for HTTP URLs, so I’m not sure how seriously to take it.

Have you checked whether the username or token contain any unencoded : or @?

Depending on the context, can’t you set up a credential manager or use a deploy key instead? The latter is probably more relevant, as I assume you’re trying to set up some kind of automation.

5

Thanks for the reply,

The username/tokens did not contain any unencoded characters.

I looked into a credential manager for a while, but settled on using deploy keys instead, which work as intended. You’re completely right, this was done to set up automation. Using keys instead of tokens probably fits our use case better anyways, but I still find it odd how cloning with username:token@repo.git seems to work for everyone else. Oh well :smiley: