When we want to restrict the access to the package we made but we don’t want to pay for a service like Private Packagist, we can use GitLab and create a token based authorization to access the package. Let’s see how!
Getting Started
Let’s say, we have a working package, what we store in a GitLab repository. By some reason, we don’t want to make it publicly accessible for composer by adding it to the public Packagist package repository. We want to restrict the access to the package, but we also want to use it the same way what we got used to.
Need a Laravel expert? We can help you to create your next performance-based, scalable, and robust project.
Preparing the composer.json file
Since we don’t load the repository from the public Packagist registry, we need to add it manually to the composer.json file. Let’s take a look at an example composer file:
"repositories": [
{
"type": "vcs",
"url": "https://gitlab.com/pinecode/example"
}
],
"require": {
"php": ">=7.0.0",
"fideloper/proxy": "~3.3",
"laravel/framework": "5.5.*",
"laravel/tinker": "~1.0",
"thepinecode/example": "0.*"
}
As you can see, we just add an object to the repositories array. In the require section we reference the name of the package what we defined in the package’s composer.json file. In this case, the package name is thepinecode/example what is hosted at the https://gitlab.com/pinecode/example repository.
From now, if we run composer update or the composer install commands, it will check the git repository and install the package that matches the given name.
Generating the access token to the user
Of course, if the repository is private, only those users can access who has the rights to read the repository. To make it accessible to other users the process should be the following:
First, we need to add a user to the repository. We can send the invitations at the repository settings menu at the “members” section. We can give them different permissions and roles, but to read the repository the Guest role is perfectly enough.
After the user has the access to the repository, it has to generate an access token to its profile. Let’s create a token for ourselves now. Choose the api scope, what enables to use the GitLab API by the given token, that means we have the access to the repositories.
After it’s done, we need to add the fresh key to the composer file, to ensure the authentication when it updates or installs packages.
Adding the access token to the composer settings
We are interested in how can we identify a request and access to the private repository we need. Actually, composer makes it very easy. We can extend our composer.json file with the following lines:
"config": {
"preferred-install": "dist",
"sort-packages": true,
"optimize-autoloader": true,
"gitlab-token": {
"gitlab.com": "your-token-here"
}
}
We can add the token we generated at GitLab. If we have the access to the repository and we defined the token, whenever we run a composer command what hits the URL of the repository it can fetch the latest information about the package. From here everything goes in the same way.
Summary
This solution works well but requires you to share the repository manually with others. After it’s done they need to generate a token what makes them able to connect to the repository. So, if you want to protect your package and share it with some developers this approach would be fine. Of course, for a bigger audience, you may consider using the Private Packagist service.
