Skip to content

Fix the npm instance level API with subgroups

Context

The npm package registry can be accessed at two "levels":

  • project. The url used will be: https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
  • instance. The url used will be: https://gitlab.example.com/api/v4/packages/npm/

At the instance level, you can see that we don't have any hint on the project or group. That is why we have a naming convention: the scope of the npm package must match the root namespace path.

With !53266 (merged), we removed this naming convention from the project level but kept it for the instance level. What we changed is that at the instance level, we extract the package scope and search for a namespace.

The issue with that code is that the search is too wide: it includes subgroups. So given a package named @my-group/my-package, the backend will look for:

  1. Any root namespace with path my-group
  2. Any sub group with path my-group. For example, a subgroup located at my-root-group/my-group, would be returned.

(2.) is certainly something we don't want as those packages don't follow the naming convention.

In short: let’s say that I want to pull a package @my-scope/my-package

  • If there is a root group with a path my-scope and without any subgroup with path my-scope, it works as expected.
  • If there is a root group with a path my-scope and a subgroup with path my-scope that has been created after the root group, it works as expected.
  • If there is a root group with a path my-scope and a subgroup with a path my-scope that has been created before the root group, the package is not found = on gitlab.com, the request is forwarded to npmjs.org.

This is ~bug #321958 (closed)

🔬 : What does this MR do?

  • Basically, I needed a scope to only fetch root namespaces. Such scope exist in the EE part.
    • The NPM API being in the non EE side of the codebase, I moved that scope from the EE model to the non EE model
  • Update the NPM API part to only look for root namespaces
  • Update the related specs
    • While at it, I noticed that we don't have spec examples when the Namespace is a user namespace. I update the shared specs to have those conditions too.

🔭 Screenshots (strongly suggested)

Check the screenshots in !53266 (merged)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

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 @gitlab-com/gl-security/appsec
  • [-] 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
Edited by David Fernandez

Merge request reports