Skip to content

read_user scope should be able to access /api/v4/version URL

Use case

We are using a little (Ruby) script locally, to check the latest available GitLab version by querying https://gitlab.com/api/v4/version and https://git.our-organization.foo/api/v4/version, and comparing the versions returned. To be able to do this, we would like to use API tokens with as little privileges as possible.

Problem

Until now, I've run this on my local Linux desktop through a cron job, with my personal user accounts and a pair of fairly permissive token (api access). I tried deploying this now to our GitLab server instead, to reduce the dependency on non-production machines for internal tools. While doing so, I tried to create an API token with read_user access instead of api. However, doing so gives me the following error when running towards https://gitlab.com/api/v4/version:

{"error"=>"insufficient_scope", "error_description"=>"The request requires higher privileges than provided by the access token.", "scope"=>"api"}

Suggested solution

In an ideal world, /version requests wouldn't even require any authentication to begin with, since it's information that could be considered "public" anyway. However, in line with the "don't give information to attackers" idea, I can live with the /version request requiring authentication; it's also easier in terms of preventing DoS attacks by throttling/blocking excessive numbers of requests from a given user.

But: it still feels like all authenticated users should be able to request the /version information. The current check (which seems to ensure that the user has api scope) could therefore be relaxed to just "ensure that user is authenticated".

Do you see any problems with the suggestion given above?

See also

  • #44327 (moved). I think solving that issue (which would be another way to workaround this issue) would be a lot more work than just solving this particular issue though.