[go: up one dir, main page]
Skip to content

Administrator Personal Access Tokens cannot create or update items via the Protected Branches API unless they are invited as a project member

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

As of GitLab 16.0.0, Administrator user Personal Access Tokens can no longer be used to interact with the Protected Branches API for create or update methods when the Administrator user in question is not a member of the project.

Example scenario

  1. Generate a Personal Access Token for an Administrator user with the API scope.

  2. Attempt to create or update a protected branch in a project that the Administrator user is not a member of, for example with:

    curl -k --request POST --header "PRIVATE-TOKEN: <admin-user-pat>" "https://example.gitlab.com/api/v4/projects/<project-id>/protected_branches?name=test"

  3. The request will be rejected with a 403 Forbidden response. (This request will work in versions of GitLab before 16.0.0)

What is the current behavior?

  • The request is rejected with a 403 Forbidden response unless the Administrator user that the token belongs to, is a member of the project the actions are being performed against.

What is the desired behavior?

  • It's unclear if this change in behavior is intentional or not at this point - However, for context, this issue was raised in reaction to a customer support ticket, where updating from GitLab 15.11.0 to 16.3.4 caused certain automation using the protected branches API to stop working, in cases where an Administrator PAT was used as an individual token to make changes across many distinct groups and projects. Inviting the Administrator user to every relevant group or project is a possible workaround but not desirable. In the customer's case their desired behavior is for Administrator PATs to work the same way as they did in 15.11.x for this scenario.

Additional testing / workarounds

  • It's suspected that changes within the ee/app/models/concerns/ee/protected_ref_access.rb file on the following commit have caused the difference in behavior:
    • Remove admin override for ProtectedRef Access

      • As a quick/dirty test workaround on an Omnibus instance, if that file is replaced with a version from an earlier commit, the Administrator token can be used again in the same way as what was possible prior to GitLab 16.0.0 (This is only for test purposes to identify the potential cause of the issue and not recommended as an actual workaround to use in production.)

        mv /opt/gitlab/embedded/service/gitlab-rails/ee/app/models/concerns/ee/protected_ref_access.rb /opt/gitlab/embedded/service/gitlab-rails/ee/app/models/concerns/ee/protected_ref_access.rb.bak
wget -O /opt/gitlab/embedded/service/gitlab-rails/ee/app/models/concerns/ee/protected_ref_access.rb https://gitlab.com/gitlab-org/gitlab/-/raw/bc773fba7355061dfb3b12163de716b48c3558d6/ee/app/models/concerns/ee/protected_ref_access.rb
gitlab-ctl restart puma
Edited by 🤖 GitLab Bot 🤖