feat: allow white listing groups

[nicolasbouffard]

We recently forked a repository which uses Lerna. Say the main package is called A and has "sub-packages" called B and C. With this plugin's current implementation of permissions, we would only have been able to publish our updated versions of A, but not B nor C, because the project's repository is called A.

This PR allows to add an option gitlabUserGroupWhitelist (which is a space-separated list) at the package level, to allow to bypass the usual permissions checks if the user belongs to any of the specified groups. For example :

packages:
  '**':
    access: $authenticated
    publish: $authenticated
    proxy: npmjs
    gitlab: true
    gitlabUserGroupWhitelist: org_name

This allows us to grant access to all members of our organization, regardless of the projects naming scheme.

[nicolasbouffard]

I changed my PR to satisfy another of our use-case.

DISCLAIMER : I do not recommend accepting this PR in its current state, as I diverted the caching mechanism of this plugin to solve a limitation with the current implementation of Verdaccio's plugins' authentication mechanism. This was done in order to get something working quickly, but in order to have something clean, Verdaccio itself might need some rework.

We needed to be able to do something like this for example :

• Our registry is only accessible (whether it is for access or publish) to members of the GitLab group "organization" ;
• Users dev1 and dev2 have the maintainer role in GitLab ;
• User builder has the developer role in GitLab (this is a "dummy" user for a build machine) ;
• Users with the maintainer role are allowed to read and write to the npm registry ;
• Users with the developer role are only allowed to read from the npm registry.

The fact is that the way the authentication currently works with Verdaccio's plugins system, it doesn't differentiate between access and publish requests. So when an authentication plugin returns the groups a user has access to, it cannot return multiple sets of groups (i.e. : one set for access and one for publish).

With this PR, the following is done :

• The caching mechanism is always enabled ;
• The user can pass an additional option accessLevel, similar to the publishLevel one ;
• Two sets of groups are fetched from GitLab and stored in the cache :
  • One for accessing packages, based on the accessLevel ;
  • One for publishing packages, based on the publishLevel.
• The allow_access and allow_publish functions use the cache instead of the user parameter returned by the authenticate function, to be able to use the appropriate set of groups stored in the cache by the authenticate function ;
• For both access and publish, a check is made against the white listed GitLab groups defined in gitlabUserGroupWhitelist if defined (as a space-separated list), to ensure that the user is indeed a member of at least one of the required groups.

Edit : I added comments in the changes section to explain a bit every part.

[bufferoverflow]

@nicolasbouffard Thanks for all the details!

[dlouzan]

@nicolasbouffard @bufferoverflow Did I miss some conversation in the background about this? The PR was just closed.

[dlouzan]

@nicolasbouffard Regarding your comments about verdaccio's plugin system maybe needing two sets of permissions for access and publish, please read my comments a while ago and the corresponding issue https://github.com/verdaccio/verdaccio/issues/916 :-)

[nicolasbouffard]

@nicolasbouffard @bufferoverflow Did I miss some conversation in the background about this? The PR was just closed.

I deleted my branch by mistake (I merged it in my fork), which closed the PR automatically. I figured that since this PR is kind of a hack (see the disclaimer above), It wasn't worth to re-open it and I should just leave it there for posterity.

@nicolasbouffard Regarding your comments about verdaccio's plugin system maybe needing two sets of permissions for access and publish, please read my comments a while ago and the corresponding issue verdaccio/verdaccio#916 :-)

I didn't see your issue when doing my research (neither the one on verdaccio-gitlab, nor the one on verdaccio... guess I went a bit too fast to the coding part, due to the urgency of this feature for us ><). I'll read those more thoroughly later, but it seems that we went roughly the same path in order to have something usable in the meantime, and the implementation I made in my PR suits our needs for now.

But thanks for reaching out and reminding us about your work ! ;-)