Info: Owned groups vs Master access

[drubin]

I would like to know why your intention of only limiting it to owned groups vs groups a user has write access to?

Seems like something that doesn't really match up. In most cases, Master access seems to make more sense.

Is this due to a limitation on the gitlab api API? https://docs.gitlab.com/ce/api/groups.html#list-groups

[bufferoverflow]

I agree master would make sense. However, we would need a nice api on gitlab side to get groups where the authenticated person is master in a similar way as owner=true on the group api endpoint. Otherwise, we have to do a lot of queries during the authentication phase and that's definitive not what a like to do.

[bufferoverflow]

GitLab 11.2 will support privide the option to request min_access_level, see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20478

[bufferoverflow]

I think we should create global options, one for access with Reporter as default and one for publish with Maintainer as default.

See:

• https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions
• https://docs.gitlab.com/ce/api/access_requests.html

[dlouzan]

How should we approach gitlab version compatibility? We have several options here:

• We release this functionality as a new verdaccio-gitlab major version, requires gitlab 11.2+
• We make the code compatible with e.g. at least gitlab 11.x (or whichever version the owner api functionality was added in) and default to the current owner-only functionality in case we are not in 11.2+. For this we need an endpoint in gitlab to identify the api version, I'll check the documentation.
• ???

[drubin]

They offer a version API https://docs.gitlab.com/ee/api/version.html but it requires authentication which is against the plugin's goals.

I believe we could leave the default behaviour as it currently is and introduce a new config which switches to this new functionality.

Then later we could release a major version upgrade that makes this the default if we want.

I wouldn't have an issue either way as either way it will require us to change something.

[dlouzan]

Ok, I think I'll have a first working implementation by the end of today, I'll work on a feature branch and let's see what @bufferoverflow thinks of this.

[dlouzan]

@bufferoverflow
I'm still working with the code in my own branch, but I'm faced with the following issues.

I'm working on a configuration like this:

auth:
  gitlab:
    url: http://gitlab
    authCache:
      enabled: true
      ttl: 300
    # $min_access_level or $owner
    accessControl: $min_access_level

packages:
  '@*/*':
    # scoped packages
    access: $gitlab_reporter
    publish: $gitlab_maintainer
    proxy: npmjs
    gitlab: true

  '**':
    access: $gitlab_reporter
    publish: $gitlab_maintainer
    proxy: npmjs
    gitlab: true

The accessControl: $owner would replicate the previous behaviour; the accessControl: $min_access_level implements the new functionality.

Each package definition would allow to set the access and publish rules independently, with the possible values:
$all | $authenticated | $gitlab_guest | $gitlab_reporter | $gitlab_developer | $gitlab_maintainer | $gitlab_owner

We would need to query the groups for a user twice, once for access and another for publish, since the groups will be different depending on the access or publish operations. The auth cache can be extended to support this.

@juanpicado The main issue is how to pass two different sets of groups between authenticate and allow_access / allow_publish. We only have the credentials of the user in the authenticate call, so it's the only location in which I can query gitlab and then we can set the groups of the user in the callback. These groups are then available later as real_groups in allow_access and allow_publish.

Those two sets of groups will be different on access or publish, I need a way to store the sets and reference them appropriately. I could probably use the in-memory cache, but we made that an optional functionality, so I can't depend on it being always available.

Any ideas?

[dlouzan]

@bufferoverflow And now that I think about it a bit more in detail, I think that if we allow to configure the access level on each package definition, we potentially need to query a set of groups for each combination min_access_level - user, since all combinations might be possible. Maybe we prefer to set this min_access_level as a fixed plugin configuration for all packages, and not a per-package configuration. In that case, we only have to query max. each user groups twice.

[bufferoverflow]

@dlouzan we should implement this as simple as possible. One global gitlab configuration option for publish and one for access. This requires two gitlab api calls during login and caching for access and publish groups.

auth:
  gitlab:
    url: http://gitlab
    authCache:
      enabled: true
      ttl: 300
    access: 20
    publish: 40

Other options should stay as is.

[dlouzan]

@bufferoverflow Ok, I'm on it
@juanpicado Any idea if it's possible to implement the passing of multiple sets of groups between authenticate and allow_access / allow_publish without relying on the cache? Right now I can only pass a single string array group list.

[dlouzan]

@bufferoverflow A functional version is uploaded

For this initial version, I'm only applying the min_access_level configuration to publish operations, access operations are still using the previous logic (authenticated users are always allowed to view packages, unauthenticated only those packages that have a verdaccio rule $all set).

The reason for this is that there's no support at the moment for passing multiple sets of permissions between the plugin methods, the current API only supports a single group set, and we need one for access and another for publish. I'm in contact with @juanpicado to see if we can find a proper solution. There's also ways to do it via the cache, but I think they're quite ugly.

Additionally, today I found two potential flaws in our current gitlab logic:

1. If we enable a rule for access e.g. access: $reporter, there's no way to download then any public package from the upstream registries. Users will never be part of a group for those packages, and verdaccio will reject their downloads. We need to think a bit about this, I think the use case would be to protect some specific groups depending on their gitlab configuration, so maybe we need to, by default allow authenticated users to download, and only reject access when a specific group exists in gitlab but is not public and doesn't match the access level configured. There's also the issue of name collisions (e.g. a public package that has the same name as a group in gitlab). This requires some careful thinking.
2. I also think we might have name collisions between user names and existing public packages or groups. Our logic at the moment is to add a group to each user that matches their own user id. Wouldn't this give rights to e.g. a user named verdaccio to the verdaccio package?

[juanpicado]

@dlouzan I have not a clear idea about how to answer you yet, I'm working currently on new token support and some things might change. I'll let you know the outcome of it.

[dlouzan]

After googling a bit and doing some diagrams, I think a workable approach would be to define an npm package-name-friendly prefix in the verdaccio-gitlab config and then mandate all custom, non-public registry packages to be prefixed with it. If the prefix is well chosen, the probability of collisions is minimal and it also has the advantage of making very clear which packages belong to the private registry.

Something like:
prefix: my.org.com

And then names like:

• my.org.com_mypackage
• @my.org.com_mygroup/mypackage

I will do some more thinking and check some scenarios in paper.

[drubin]

@dlouzan We would never be able to upgrade if you forced this level of breaking change.

Why is this an issue? Why would you want to enforce this level of prefixes?

It's not the job of a plugin/verdacio to figure out if the package was internal or private, Its the job to match the configuration and apply the access rules.

Verdacio allows for easily overriding public packages if need be, Those, however, should follow the same authentication policy as defined in the config.