Any login is accepted with personal access token while cloning a repository
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=212953) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### 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 <details> <summary> Results of GitLab application Check </summary> # 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 ``` </details>
issue