Skip to content

Add ci job token support to the Composer packages registry

What does this MR do and why?

Allows the CI/CD Job Token to have :read_package permission for any of the Package APIs.

Because I had added this permission, it also inadvertantly make a bunch of other tests fail. This is because the CI/CD Job Token was now blanketly given permission to :read_package, and since a Project by default is now created with the Allowlist feature, and that the project is self-referencing, these tests failed

Developer and Guest Membership

I am just a contributor here, but is the :developer, :guest etc Member types really applicable to CI/CD Job Tokens? Since this isn't configurable in any way when a job runs.

Because of this I have added another rule that If the user is a CI/CD Job Token and the job project is the project being accessed, the Job token now also has access to :read_project and :create_package.

There has been a bit of scope creep from the original purpose of this MR, but it was either that, or rework the entire test structure to support the added permission

Composer API

This MR was originally intended for Composer to be used with the Job Token. However the composer program itself only sends the token along as PRIVATE-TOKEN header.

I propose to modify the Composer program itself to conditionally select PRIVATE-TOKEN or JOB-TOKEN based on the token auth

See https://github.com/composer/composer/blob/main/src/Composer/Util/AuthHelper.php#L255

Requesting feedback as some tests are failing, and I've yet to understand the fallthrough of guests/anonymous users through the addition of a single override rule

Related Issue: #24269

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Muhammed Ali

Merge request reports