verdaccio/website/translated_docs/it-IT/best-practices.md

id	title
best	Migliori Pratiche

La guida seguente è un elenco delle migliore pratiche raccolte e che raccomandiamo solitamente a tutti gli utenti. Non considerare questa guida come obbligatoria, puoi selezionare qualcuna di esse a seconda delle tue esigenze.

Feel free to suggest your best practices to the Verdaccio community.

Registro Privato

È possibile aggiungere utenti e gestire quali utenti possono accedere a quali pacchetti.

È raccomandabile definire un prefisso per i tuoi pacchetti privati, per esempio local-* o @my-company/* con scope, così che tutti i tuoi elementi privati appariranno così: local-foo. In questo modo si possono separare chiaramente i pacchetti pubblici da quelli privati.

 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.

Utilizzo dei pacchetti pubblici da npmjs.org

Se un pacchetto non esiste nell'archivio, il server proverà a recuperarlo da npmjs.org. Se npmjs.org non risponde, fornirà solo i pacchetti presenti nella cache. Verdaccio scaricherà solo ciò che è necessario (richiesto dai client) e questa informazione verrà memorizzata nella cache, così se il client chiederà la stessa cosa una seconda volta, potrà ottenerla senza la necessità di interrogare nuovamente npmjs.org.

Esempio:

Se fai una richiesta per il pacchetto express@4.0.1 da questo server che va a buon fine una volta, sarà possibile farla un'altra volta (con tutte le sue dipendenze) in ogni momento, anche con npmjs.org non funzionante. Nota bene che express@4.0.0 non verrà scaricato fino a quando non sarà effettivamente necessario a qualcuno. 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.

Annullare pacchetti pubblici

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. Desideri creare un fork separato e interrompere la sincronizzazione con la versione pubblica.

   If you want to do that, you should modify your configuration file so Verdaccio won't make requests regarding this package to npmjs anymore. Aggiungi una voce separata per questo pacchetto a config.yaml, rimuovi npmjs dalla lista proxy e riavvia il server.

   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.

   Per evitare conflitti delle versioni, dovresti usare un suffisso personalizzato rilasciato prima della successiva versione della patch. Per esempio, se un pacchetto pubblico ha la versione 0.1.2, puoi fare l'upload di 0.1.3-my-temp-fix.

   npm version 0.1.3-my-temp-fix
   npm publish --tag fix --registry http://localhost:4873
   

   In questo modo il tuo pacchetto verrà utilizzato fino a che il suo manutentore originale aggiorna il suo pacchetto pubblico alla 0.1.3.

Sicurezza

Security starts in your environment.

Additonal reading:

• 10 npm Security Best Practices and following the steps outlined there.
• Avoiding npm substitution attacks
• Dependency Confusion: When Are Your npm Packages Vulnerable?
• Practical Mitigations For Dependency Confusion Attack > Feel free to attach here new useful articles to improve the security.

Strong package access with $authenticated

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.

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.

Remove proxy to increase security at private packages

After a clean installation, by default all packages will be resolved to the default uplink (the public registry npmjs).

packages:
  "@*/*":
    access: $authenticated
    publish: $authenticated
    proxy: npmjs
  "**":
    access: $authenticated
    publish: $authenticated
    proxy: npmjs

This means, if a private packaged eg: @my-company/auth is published locally, the registry will look up at the public registry. If your intention is fully protection, remove the proxy property from your configuration, for instance:

packages:
  "@my-company/*":
    access: $authenticated
    publish: $authenticated
    unpublish: $authenticated
  "@*/*":
    access: $authenticated
    publish: $authenticated
    proxy: npmjs
  "**":
    access: $authenticated
    publish: $authenticated
    proxy: npmjs

This configuration will avoid downloading needlessly to external registries, merging external metadata and download external tarballs.

Server

Secured Connections

Using HTTPS is a common recommendation. For this reason we recommend reading the SSL section to make Verdaccio secure, or alternatively using an HTTPS reverse proxy on top of Verdaccio.

Expiring Tokens

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

security:
  api:
    jwt:
      sign:
        expiresIn: 15d
        notBefore: 0
  web:
    sign:
      expiresIn: 7d

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.