Repository files navigation

UseGitLab Community Editionas authentication provider for the private npm registryVerdaccio, the sinopia fork.

The main goal and differences from other sinopia/verdaccio plugins arethe following:

• no admin token required
• user authenticates with Personal Access Token
• access & publish packages depending on user rights in gitlab

This is experimental!

You need at least node version 8.x.x, codenamecarbon.

git clone https://github.com/bufferoverflow/verdaccio-gitlab.gitcd verdaccio-gitlabyarn installyarn start

NOTE: Definehttp_proxy environment variable if you are behind a proxy.

Verdaccio is now up and running. In order the see this plugin in action, you canuse the following Verdaccio configuration in your~/.config/verdaccio/config.yaml.

# Verdaccio storage location relative to $HOME/.config/verdacciostorage:./storagelisten:  -0.0.0.0:4873auth:gitlab:url:https://gitlab.comuplinks:npmjs:url:https://registry.npmjs.org/packages:'@*/*':# scoped packagesaccess:$allpublish:$maintainerproxy:npmjsgitlab:true'**':access:$allpublish:$maintainerproxy:npmjsgitlab:true# Log level can be changed to info, http etc. for less verbose outputlogs:  -{type: stdout, format: pretty, level: debug}

Restart Verdaccio and authenticate into it with your credentials

• Username: GitLab username
• Password:Personal Access Token

using the Web UIhttp://localhost:4873 or via npm CLI:

yarn login --registry http://localhost:4873

and publish packages:

yarn publish --registry http://localhost:4873

Access and publish access rights are mapped following the rules below.

verdaccio-gitlab access control will only be applied to package sections thatare marked withgitlab: true as in the configuration sample above. If youwish to disable gitlab authentication to any package config, just remove theelement from the config.

access is allowed depending on the following verdacciopackage configurationdirectives:

• authenticated users are able to access all packages
• unauthenticated users will be able to access packages marked with either$all or$anonymous access levels at the package group definition

Please note that no group or package name mapping is applied on access, anyuser successfully authenticated can access all packages.

publish is allowed if:

1. the package name matches the GitLab username, or
2. if the package name or scope of the package matches one of theuser's GitLab groups, or
3. if the package name (possibly scoped) matches on the user'sGitLab projects.

For 2. and 3., the GitLab user must have the access rights on the group orproject as specified in theauth.gitlab.publish setting.

For instance, assuming the following configuration:

auth:gitlab:publish = $maintainer

The GitLab usersample_user has access to:

• Groupgroup1 as$maintainer
• Groupgroup2 as$reporter
• Projectgroup3/project as$maintainer

Then this user would be able to:

• access any package
• publish any of the following packages:
  • sample_user
  • group1
  • any package under@group1/**
  • @group3/project

There would be an error if the user tried to publish any package under@group2/**.

The full set of configuration options is:

auth:gitlab:url:<url>authCache:enabled:<boolean>ttl:<integer>publish:<string>

In order to avoid too many authentication requests to the underlyinggitlab instance, the plugin provides an in-memory cache that will savethe detected groups of the users for a configurable ttl in seconds.

No clear-text password is saved in-memory, just an SHA-256 hash ofthe user+password, plus the groups information.

By default, the cache will be enabled and the credentials will be storedfor 300 seconds. The ttl is checked on access, but there's also aninternal timer that will check expired values regularly, so data ofusers not actively interacting with the system will also be eventuallyinvalidated.

Please note that this implementation is in-memory and notmulti-process; if the cluster module is used for starting severalverdaccio processes, each process will store its own copy of the cache,so each user will actually be logged in multiple times.

git clone https://github.com/bufferoverflow/verdaccio-gitlab.gitcd verdaccio-gitlabdocker-compose up --build -d

• login with userroot and passwordverdaccio on Gitlab viahttp://localhost:50080
• create a Personal Access Token
• login to the npm registryhttp://localhost:4873 via browser
• publish your packages via command line

The Dockerfile provides adefault configuration filethat is internally available under/verdaccio/conf/config.yaml. In orderto overwrite this configuration you can provide your own file and mount iton docker startup with the--volume option, or equivalent mechanism(e.g. ConfigMaps on Kubernetes / OpenShift with thehelm chart).

Please adhere to theverdaccio community guidelinesand run all the tests before creating a PR. The commit message shall follow theconventional changelog as it is enforced via local commit hook using husky andthe@commitlint/config-conventionalrule set.

PR's that do not pass CI will not be reviewed.

Run one of the following command to create a release:

yarn release:majoryarn release:minoryarn release:patch

finally run

yarn publish

In order to run functional tests with debug output, set theVERDACCIO_DEBUG=true environment variable,as documented by verdaccio:

VERDACCIO_DEBUG=true yarn test:functional

MIT