Add unit tests for all possible Git clone scenarios
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
TL;DR - We should add test cases for each of the possible Git request scenarios shown in the After the fix table below
The following discussion from gitlab-ce!31632 should be addressed:
-
@tmaczukin started a discussion: (+3 comments)
OK, this idea is so crazy, that I've decided do some manual test. And indeed, for each clone using git+http protocol, even if I will explicitly set the credentials (for example by executing git clone https://my-username:my-password@gitlab.example.com:some/project.git), git drops the credentials and tries to access the remote repository without any authentication. If the repository is protected it should return 401 Unauthorized and in that case git will repeat the request, but this time using the credentials provided by the user.
And this generates 16 possible scenarios:
Before the fix
| HTTP protocol enabled | HTTP protocol disabled | |
|---|---|---|
public project, user:password credentials used |
200 | 403 |
non-public project, user:password credentials used |
401 + 200 | 401 + 403 |
public project, gitlab-ci-token:token credentials used |
200 | 403 |
non-public project, gitlab-ci-token:token credentials used |
401 + 200 | 401 + 200 |
After the fix
| HTTP protocol enabled | HTTP protocol disabled | |
|---|---|---|
public project, user:password credentials used |
200 | 401 + 403 |
non-public project, user:password credentials used |
401 + 200 | 401 + 403 |
public project, gitlab-ci-token:token credentials used |
200 | 401 + 200 |
non-public project, gitlab-ci-token:token credentials used |
401 + 200 | 401 + 200 |
-
200means that the first, unauthenticated request passed and git returned the source code. Even if the credentials were used in the URL, git didn't use them and GitLab accepted the request. -
401 + 200means that the first, unauthenticated request was rejected, but git repeated it - this time using credentials provided in the URL - and the repeated request was accepted by GitLab. -
401 + 403means that the first, unauthenticated request was rejected and the second request - using the credentials provided in the URL - was also rejected. -
403means that the first, unauthenticated request was rejected, but because it's403git doesn't repeat it and fails.
As we can see all cases except public project with CI credentials when HTTP is disabled are working as we could expect it. This one case fails exactly as @dblessing described it: the initial check doesn't return 401 (which would force git to retry the request with credentials) and GitLab tries to process it further, but next the request is failing on http disabled rule and this one returns 403. And for git 403 means: "I've been authenticated and my request was still rejected. Let's fail."
This fix seems to work properly. The scenarios when HTTP is enabled are unchanged, and when HTTP is disabled two scenarios are changed:
- for public project and user credentials GitLab will now force git to do the additional request, but still fail it at the end (which is expceted),
- for public project and CI credentials GitLab will now force git to do the additional request, and since it will use the CI job token, the request will skip the
http disabledcheck and will handle the request properly.
@dblessing We've recently had few customer reports that CI clones are not working when HTTP is disabled. Are we able to confirm that all of these were happening only for public projects in customer's GitLab installations? Because this seems to be the only case when the CI clone may fail with 403.