You can add users and manage which users can access which packages.
It is recommended that you define a prefix for your private packages, for example `local-*` or scoped `@my-company/*`, so all your private things will look like this: `local-foo`. This way you can clearly separate public packages from private ones.
```yaml
packages:
'@my-company/*':
access: $all
publish: $authenticated
'local-*':
access: $all
publish: $authenticated
'@*/*':
access: $all
publish: $authenticated
'**':
access: $all
publish: $authenticated
```
Always remember, **the order of packages access is important**, packages are matched always top to bottom.
If a package doesn't exist in the storage, the server will try to fetch it from npmjs.org. If npmjs.org is down, it serves packages from the cache pretending that no other packages exist. **Verdaccio will download only what's needed (requested by clients)**, and this information will be cached, so if the client requests the same thing a second time it can be served without asking npmjs.org for it.
**Example:**
If you successfully request `express@4.0.1` from the server once, you'll be able to do it again (with all of it's dependencies) any time, even if npmjs.org is down. Though note that `express@4.0.0` will not be downloaded until it's actually needed by somebody. And if npmjs.org is offline, the server will say that only `express@4.0.1` (what's in the cache) is published, but nothing else.
If you want to use a modified version of some public package `foo`, you can just publish it to your local server, so when your type `npm install foo`, **it'll consider installing your version**.
There's two options here:
1. You want to create a separate **fork** and stop synchronizing with public version.
If you want to do that, you should modify your configuration file so Verdaccio won't make requests regarding this package to npmjs anymore. Add a separate entry for this package to `config.yaml` and remove `npmjs` from `proxy` list and restart the server.
```yaml
packages:
"@my-company/*":
access: $all
publish: $authenticated
# comment it out or leave it empty
# proxy:
```
When you publish your package locally, **you should probably start with a version string higher than the existing package** so it won't conflict with that package in the cache.
2. You want to temporarily use your version, but return to the public one as soon as it's updated.
In order to avoid version conflicts, **you should use a custom pre-release suffix of the next patch version**. For example, if a public package has version 0.1.2, you can upload `0.1.3-my-temp-fix`.
- **[Dependency Confusion: When Are Your npm Packages Vulnerable?](https://blog.includesecurity.com/2021/02/dependency-confusion-when-are-your-npm-packages-vulnerable/)**
- **[Practical Mitigations For Dependency Confusion Attack](https://www.kernelcrypt.com/posts/depedency-confusion-explained/)**
> Feel free to attach here new useful articles to improve the security.
By default all packages you publish in Verdaccio are accessible for all users. We recommend protecting your registry from external non-authorized users by updating the `access` property of your packages to `$authenticated`.
```yaml
packages:
"@my-company/*":
access: $authenticated
publish: $authenticated
"@*/*":
access: $authenticated
publish: $authenticated
"**":
access: $authenticated
publish: $authenticated
```
That way, **nobody can access your registry unless they are authorized, and private packages won't be displayed in the web interface**.
This means that even if a private package like `@my-company/auth` is published locally, the server will look up at the public registry. If that's not your intention, remove the `proxy` property and use a configuration like this one:
Using **HTTPS** is a common recommendation. For this reason we recommend reading the [SSL](ssl.md) section to make Verdaccio secure, or alternatively using an HTTPS [reverse proxy](reverse-proxy.md) on top of Verdaccio.
Since `verdaccio@3.x` the tokens have no expiration date. For such reason we introduced in the next `verdaccio@4.x` the JWT feature [PR#896](https://github.com/verdaccio/verdaccio/pull/896)
**Using this configuration will override the current system and you will be able to control how long the token will live**.
Using JWT also improves the performance with authentication plugins. The old system will perform an unpackage and validate the credentials on every request, while JWT will rely on the token signature instead, avoiding the overhead for the plugin.
As a side note, be aware at **npmjs** and the **legacy** verdaccio token never expires\*\* unless you invalidate manually.
Since version `v5.4.0` critical endpoints have enabled by default rate limit. The following commands are considered user endpoints:
-`npm token` all variants
-`npm login/adduser`
-`npm profile` all supported variants
- User website `/sec/login` endpoint.
The previous list of endpoints are limited to `100` request peer _15 minutes_ which is enough for a basic usage, if you need to increase this levels please check the `userRateLimit` configuration options.
```yaml
userRateLimit:
windowMs: 50000 <-(minutes* 60 *1000)
max: 1000 (number of request peer windowMs)
```
The website endpoints as, _search_, _packages_, _sidebar_, and _detail_ are protected by default to 5,000 request peer 2 minutes, also configurable via web ui options.
We recommend customize this values to those that addapt your needs to avoid any kind of (DDoS) or _brute-force_ attack to the critical endpoints.
> The CLI API endpoints used by eg `npm install` are not limited at this point since are not considered critical, but if you find any good reason please open a discussion.
