Unable to download job artifacts using an access token with read_repository permissions since upgrade from 11.4.6-ee.0 to 11.5.4-ee.0

Summary

Unable to download job artifacts using an access token with read_repository permissions since upgrade from 11.4.6-ee.0 to 11.5.4-ee.0

Steps to reproduce

We have a deployment job that runs every 30 minutes that runs the following command /usr/bin/wget --header='Private-Token: xxxx' http://gitlab.domain.com/group/project/-/jobs/artifacts/master/download?job=build-prod -O /opt/vendor/product/latest.zip

What is the current bug behavior?

Redirect to the sign-in page is served

What is the expected correct behavior?

Historically, this successfully downloaded the latest job archive and worked reliably. I am aware that the API can be used for this, but I don't like the idea of giving full R/W to the API to the user downloading these files. We use pull based deployment, not push. Therefore Gitlab has no access to our servers. The servers need access to gitlab. As we're building javascript bundles for web and/or compiling applications, we do not want to clone the repo and build on the target - we build using runner and deploy the finished article.

Relevant logs and/or screenshots

--2019-01-08 11:02:49--  http://gitlab.domain.com/group/project/-/jobs/artifacts/master/download?job=build-prod
Resolving gitlab.domain.com (gitlab.domain.com)... w.x.y.z
Connecting to gitlab.domain.com (gitlab.domain.com)|w.x.y.z|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://gitlab.domain.com/users/sign_in [following]
--2019-01-08 11:02:49--  http://gitlab.domain.com/users/sign_in
Reusing existing connection to gitlab.domain.com:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/opt/vendor/product/latest.zip’

/opt/vendor/product/latest.zip                           [ <=>                                                                ]   9.15K  --.-KB/s    in 0s      

2019-01-08 11:02:49 (121 MB/s) - ‘/opt/vendor/project/latest.zip’ saved [9372]

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		Debian 9.6
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.4.5p335
Gem Version:	2.7.6
Bundler Version:1.16.6
Rake Version:	12.3.1
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.1
Go Version:	unknown


GitLab information
Version:	11.5.4-ee
Revision:	62f48df
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
DB Version:	9.6.8
URL:		http://gitlab.kadfire.com
HTTP Clone URL:	http://gitlab.kadfire.com/some-group/some-project.git
SSH Clone URL:	git@gitlab.kadfire.com:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: bitbucket


GitLab Shell
Version:	8.4.1
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 8.4.1 ? ... OK (8.4.1)
hooks directories in repos are links: ...
3/1 ... ok
7/2 ... ok
8/3 ... ok
8/4 ... ok
8/5 ... ok
9/6 ... ok
10/7 ... ok
3/10 ... ok
7/11 ... ok
9/12 ... ok
4/13 ... ok
3/14 ... ok
8/15 ... ok
3/16 ... ok
8/17 ... ok
3/18 ... ok
3/19 ... ok
3/20 ... ok
3/22 ... ok
3/23 ... ok
3/24 ... ok
8/25 ... ok
9/26 ... repository is empty
3/27 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Reply by email is disabled in config/gitlab.yml
Checking LDAP ...


LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab ...


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? ... yes
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: ...
3/1 ... yes
7/2 ... yes
8/3 ... yes
8/4 ... yes
8/5 ... yes
9/6 ... yes
10/7 ... yes
3/10 ... yes
7/11 ... yes
9/12 ... yes
4/13 ... yes
3/14 ... yes
8/15 ... yes
3/16 ... yes
8/17 ... yes
3/18 ... yes
3/19 ... yes
3/20 ... yes
3/22 ... yes
3/23 ... yes
3/24 ... yes
8/25 ... yes
9/26 ... yes
3/27 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.5)
Git version >= 2.9.5 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 16
Elasticsearch version 5.1 - 5.5? ... skipped (elasticsearch is disabled)


Checking GitLab ... Finished

Possible fixes

Have not yet found the commit in question that changed this behaviour.

Edited by Chris Malton