I’m getting a 403 response for one project on a merge_requests api request. The projects are owned by me and the api calls are using an access token I created. merge_requests api calls on other projects work fine and other api calls like issues work fine on the suspect project. What can I do to fix this?
Running self-hosted GitLab Community Edition 12.6.1 on Ubuntu 16.04.
Hi,
is there anything suspicious in the logs for that very moment when you receive the 403 on the client?
Cheers,
Michael
Hi Michael! I haven’t found anything that stands out.
In /var/log/gitlab/gitlab-rails/production.log:
Started GET "/api/v4/projects/54/merge_requests" for xx.xx.xx.xx at 2020-01-03 07:21:49 -0800
In gitlab/railsapi-json.log:
{"time":"2020-01-03T15:21:49.747Z","severity":"INFO","duration":8.66,"db":1.55,"view":7.11,"status":403,"method":"GET","path":"/api/v4/projects/54/merge_requests","params":[],"host":"xxx","remote_ip":"xx.xx.xx.xx, xx.xx.xx.xx","ua":"curl/7.67.0","route":"/api/:version/projects/:id/merge_requests","user_id":2,"username":"arf","queue_duration":15.51,"correlation_id":"PJCpBdyXEn9"}
Is there another place I should be looking?
Hi,
I was curious about a Ruby exception which could lead to a bug, or help with further analyzing it. If there’s nothing in this regard, I’m a little out of ideas.
I would do the following: 1) create a new project with the exact same settings like the “buggy” one 2) check wether the problem persists 3) if not, fetch the project configuration via REST API from a working and non-working project and compare them attribute by attribute. That likely can be done in a programmatic fashion to speed things up.
Cheers,
Michael