Overly strict access level mappings

[zanechua]

Thanks for the work on the gitlab plugin. It works great and is easy to setup.

However, I realised that the access for publishing is pretty limited as outlined in the documentation.

I feel that the access level mapping is a little too strict for a private npm registry. It's great that those rules are able to be defined but are they even necessary? Is there any particular reason that the access rights for publishing has been mapped this way?

I have a use case that requires publishing a package name that overwrites an upstream package name. I however do not own the username nor the group.

The plugin relies on the url path of the group and not the name of the gitlab group. Therefore even though I have maintainer rights via gitlab, I am unable to publish the package without it being scoped. According to the existing rules, the following configuration:

  '**':
    access: $all
    publish: $maintainer
    proxy: npmjs
    gitlab: true

is practically useless unless I own the username or groupname.

Should that control be left to the ones maintaining the verdaccio instance?

Since you can always declare more restrictions as necessary.

[bufferoverflow]

Yes, this should be handled by the people maintaining the verdaccio instance. Overwriting packages could be an issue and security risk for other using the same verdaccio instance.

[zanechua]

I do understand that overwriting packages that use the same name could be an issue and security risk. But I'm making the assumption that most verdaccio instances are for internal use only. Hence the point of a private npm registry and that information about overwritten packages would've been communicated to the team using the instance. Anyone else using the instance that isn't authorised to do so would have another thing coming.

After I posted, I realised that the way you mapped it, is basically assuming that if you own the url path of a group, you would be able to publish to said scope. However, could the access be reworked such that you could do something like the following?

  '**':
    access: $all
    publish: $maintainer@group
    proxy: npmjs
    gitlab: true

Otherwise the ** scope with this plugin wouldn't be useful except for being able to publish as the group url path and username

Even package names that do not overwrite any upstream registry would not work and you would probably have to end up creating pseudo groups to be able to do so. But if you create a pseudo group, no one else will be able to create a pseudo group unless of course they are running their own GitLab instance.