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:
- Any root namespace with path
my-group
- Any sub group with path
my-group
. For example, a subgroup located atmy-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 pathmy-scope
, it works as expected. - If there is a root group with a path
my-scope
and a subgroup with pathmy-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 pathmy-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
-
Changelog entry - [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] 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
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