We are adding support for RubyGems in the GitLab package registry. This is the first of many MRs that will build out the API, models, and services needed to interact with the Gem client (
gem push foo), and Bundler (
bundle install). The goal of this MR is to set up the skeleton of the API behind a feature flag so we can start building out the various pieces that go along with each endpoint. In addition to defining the various routes, we also set up authentication here.
🔬 What does this MR do?
rubygems_packages.rbwith a collection of empty endpoints to support the RubyGems API
- Adds a new feature flag
:rubygem_packagesthat will stand in front of the entire API.
:token_authas a supported authentication type in
API::Helpers::Authenticationand adds a new set of resolvers.
🔒 What are
API::Helpers::Authentication? Why don't we use the normal API authentication?
API::Helpers::Authentication was recently added as the beginning of a refactor to the existing API authentication. When dealing with various package managers, we don't have the ability to choose how they will send credentials to the API. For example, if we want to accept a personal access token or deploy token from NPM, we have to accept them through Oauth headers even though they are not OAuth tokens. This has made it difficult to follow the authentication code, especially with regards to the package managers.
API::Helpers::Authentication introduces a new workflow that allows you to decorate your API class with something like:
authenticate_with do |accept| accept.token_types(:personal_access_token_with_username, :deploy_token_with_username, :job_token_with_username) .sent_through(:basic_auth) end
making it much easier to understand which authentication methods are used and which token types are accepted. Currently only the NuGet API uses this new module, but the plan is to refactor all of the package APIs over to it, and eventually the non-package APIs. Since we are adding a new package type here, we should use the new Authentication module rather than creating technical debt that we would need to refactor later.
☑ Does this MR meet the acceptance criteria?
- [-] Changelog entry Behind a feature flag
- [-] Documentation (if required)
Code review guidelines
Merge request performance guidelines
- [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
- [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
Label as security and @ mention
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
Security reports checked/validated by a reviewer from the AppSec team
Related to #299262 (closed)