Any login is accepted with personal access token while cloning a repository
Summary
It is possible to clone a repository by providing any login when using a personal access token with "write_repository" scope (probably with tokens of other scopes too). Basically, the following would work, which is a problem:
$ git clone https://anything:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
The login is necessary but its value is actually not checked. Some people might argue that the token should suffice and that the login is not necessary. Why not?
However, in that case, the login should not then be necessary. I think if the login is required, its value should be checked, and that's why I consider this being a bug.
Steps to reproduce
Create a personal access token with "write_repository" scope Try to clone a repository for which you have an access. Provide any login (even one that does not exist) as a login and the personal access token as a password. You will see that the clone works.
I noticed I could clone the repository with:
$ git clone https://{username}:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
It also works with:
$ git clone https://{token-name}:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
$ git clone https://oauth2:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
I then tried with non existing accounts, and here again, it worked, which is troublesome:
$ git clone https://anything:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
$ git clone https://johndoe:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
What is the expected correct behavior?
The username and the PAT are passed, and both are verified. This is a valid connect string:
git clone https://{username}:{personal_access_token}@<my-gitlab-server>/<group>/<repo>.git
Results of GitLab environment info
Omnibus package gitlab version 12.4.3
Results of GitLab application Check
gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 10.2.0 ? ... OK (10.2.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
2/1 ... yes
3/2 ... yes
5/3 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.3)
Git version >= 2.22.0 ? ... yes (2.22.0)
Git user has default SSH configuration? ... yes
Active users: ... 2
Is authorized keys file accessible? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished