# Documentazione Django 6.0.7

# Lista dei controlli per la distribuzione

Internet è un ambiente ostile. Prima di distribuire il tuo progetto Django, dovresti prenderti del tempo per revisionare le tue configurazioni, tenendo a mente sicurezza, performance ed gestione operativa.

Django include molte caratteristiche di sicurezza. Alcune sono built-in e sempre abilitate. Altre sono opzionali perchè non sono sempre appropriate o perchè non sono pratiche in fase di sviluppo. Per esempio, forzare HTTPS può non andare bene per tutti i siti ed è molto poco pratico per lo sviluppo locale.

Le ottimizzazioni di performance sono un’altra categoria di tradeoff con la convenienza. Per esempio, il caching è utile in produzione, meno per lo sviluppo locale. Anche l’error reporting deve essere molto differente.

La seguente lista di controlli include configurazioni come:

- devono essere configurate correttamente in Django affinché forniscano il livello di sicurezza atteso;

- ci si aspetta che siano differenti per ogni ambiente;

- abilita le funzionalità di sicurezza opzionali;

- Abilita le ottimizzazioni per le prestazioni

- fornisce le segnalazioni dell’errore.

Molte di queste impostazioni sono sensibili e dovrebbero essere trattate come confidenziali. Se stai rilasciando il codice sorgente del tuo progetto, una pratica comune è quella di pubblicare impostazioni adeguate per lo sviluppo ed usare moduli di impostazioni privati per la produzione.

## Lancia `manage.py check --deploy`

Alcuni dei check descritti qui sotto possono essere automatizzati utilizzando l’opzione `check --deploy`. Assicurati di lanciarla sul file di impostazioni della produzione come descritto nella documentazione delle opzioni.

## Switch away from `manage.py runserver`

The `runserver` command is not designed for a production setting. Be sure to switch to a production-ready WSGI or ASGI server. For a few common options, see WSGI servers or ASGI servers.

## Configurazioni critiche

### `SECRET_KEY`

La chiave segreta deve essere un valore casuale grande e deve essere tenuta segreta.

Assicurati che la chiave utilizzata in produzione non sia usata da altre parte ed evita di farne un commit verso il software di controllo dei sorgenti. Questo riduce il numero di vettori dai quali un attaccante potrebbe acquisire la chiave.

Invece di fare hardcoding della chiave segreta nelle tuo modulo di impostazioni, cosidera di caricarla da una variabile d’ambiente:

    import os

    SECRET_KEY = os.environ["SECRET_KEY"]

o da un file:

    with open("/etc/secret_key.txt") as f:
        SECRET_KEY = f.read().strip()

Se stai utilizzando la rotazione delle chiavi per i segreti, puoi usare `SECRET_KEY_FALLBACKS`:

    import os

    SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
    SECRET_KEY_FALLBACKS = [
        os.environ["OLD_SECRET_KEY"],
    ]

Assicurati che le vecchie chiavi siano rimosse prontamente da `SECRET_KEY_FALLBACKS`.

### `DEBUG`

Non devi mai abilitare la modalità debug in produzione

Stai certamente sviluppando il tuo progetto con `DEBUG = True`, perchè abilita comode feature come i traceback completi nel browser.

Per un ambiente di produzione, tuttavia, è un’idea davvero cattiva, perchè espone molte informazioni sul progetto: stralci di codice sorgente, variabili locali, impostazioni, librerie utilizzate ecc…

## Configurazione dipendente dall’ambiente

### `ALLOWED_HOSTS`

Quando `DEBUG = False`, Django non funziona affatto senza un valore adatto di `ALLOWED_HOSTS`.

Questa impostazione è necessaria per proteggere il tuo sito da alcuni attacchi CSRF. Se usi una wildcard, devi fare la tua validazione dell’header HTTP `Host` o altrimenti assicurarti di non essere vulnerabile a questa categoria di attacchi.

Dovresti anche configurare il web server che sta davanti a Django per validare l’host. Dovrebbe rispondere con una pagina di errore statica o ignorare richieste di host sbagliati invece di inoltrare le richieste a Django. In questo modo eviterai errori spuri nei log di Django (o email, se hai l’error reporting configurato in quel modo). Per esempio, su nginx potresti voler impostare un server di default che restituisca «444 No Response» per gli host sconosciuti:

    server {
        listen 80 default_server;
        return 444;
    }

### `CACHES`

Se stai usando una cache, i parametri di connessione potrebbero essere differenti tra sviluppo e produzione. Django ha come default il local-memory caching per processo, che può non essere desiderabile.

I server di cache spesso hanno una autenticazione debole. Accertati che accettino connessioni solo dai server delle applicazioni.

### `DATABASES`

I parametri di connessione al database saranno probabilmente differenti tra sviluppo e produzione.

Le password dei database sono molto sensibili. Dovresti proteggere esattamente come `SECRET_KEY`.

Per la massima sicurezza, verifica che il database accetti connessioni solo dai server applicativi.

Se non hai configurato i backup per il tuo database, fallo immediatamente!

### `MAILERS` and related settings

Se il tuo sito invia email, questi valori dovranno essere configurati opportunamente.

In development, email is often configured to be printed to the console or stored in a local file. For production, you probably want to send real email messages. Configuring email has more information about setting `MAILERS` to use production email servers.

By default, Django sends email from `webmaster@localhost` and `root@localhost`. However, many mail providers reject email from these addresses. To use different sender addresses, modify the `DEFAULT_FROM_EMAIL` and `SERVER_EMAIL` settings.

### `STATIC_ROOT` and `STATIC_URL`

I file statici sono automaticamente serviti dal server di sviluppo. In produzione, devi definire una directory `STATIC_ROOT` dove `collectstatic` li copierà.

Vedi Come gestire file statici (Es. immagini, JavaScript, CSS) per ulteriori informazioni.

### `MEDIA_ROOT` e `MEDIA_URL`

I file multimediali sono caricati dagli utenti. Sono insicuri! Assicurati che il tuo webserver non li interpreti mai. Per esempio, se un utente carica un file `.php`, il server web non dovrebbe eseguirlo.

Adesso è un buon momento per verificare la tua strategia di backup per questi files.

## HTTPS

Ogni sito web che permette agli utenti di fare login, dovrebbe applicare HTTPS per evitare la trasmissione degli access token in chiaro. In Django, gli access token includono il login/password, i cookie di sessione ed i token di reimpostazione della password. (Non puoi proteggere gran che i token di reimpostazione della password se li invii per email).

Proteggere aree sensibili quali l’account utente o l’amministrazione non è sufficiente, perchè lo stesso cookie di sessione viene usato sia per HTTP che per HTTPS. Il tuo web server deve redirigere tutto il traffico HTTP ad HTTPS, e trasmettere solo richieste HTTPS a Django.

Quando hai disposto HTTPS, abilita le seguenti impostazioni.

### `CSRF_COOKIE_SECURE`

Abilitalo a `True` per evitare di trasmettere accidentalmente il cookie CSFR su HTTP.

### `SESSION_COOKIE_SECURE`

Impostalo a `True` per evitare di trasmettere accidentalmente il cookie di sessione su HTTP.

## Ottimizzazione delle prestazioni

Impostare `DEBUG = False` disabilita molte feature che sono utili solo in fase di sviluppo. Inoltre, puoi mettere a punto le seguenti impostazioni.

### Sessioni

Considera di usare cached sessions per migliorare la performance.

Se usi le sessioni su database, pulisci le vecchie sessioni regolarmente per evitare di memorizzare dati non necessari.

### `CONN_MAX_AGE`

Abilitare le connessioni persistenti ad database può portare ad una piacevole riduzione dei tempi quando ci si connette agli account del database per una parte significativa del tempo di processamento della richiesta.

Questo aiuta molto su virtual host con prestazioni di rete limitate.

### `TEMPLATES`

Abilitare il loader dei template in cache spesso migliora drasticamente le performance, perchè evita che il template venga compilato tutte le volte che deve essere mostrato. Quando `DEBUG = False`, il loader dei template con cache è abilitato automaticamente. Vedi `django.template.loaders.cached.Loader` per avere più informazioni.

## Segnalazione errore

Nel momento in cui fai push del codice in produzione, si spera sia robusto, ma non puoi aver ragione degli errori che non ti aspetti. Per fortuna, Django cattura gli errori e te li notifica in accordo.

### `LOGGING`

Verifica la configurazione del sistema di logging prima di mettere il tuo sito in produzione, e verifica che funzioni come previsto appena inizi a ricevere del traffico.

Vedi Logging per dettagli sul logging.

### `ADMINS` e `MANAGERS`

`ADMINS` will be notified of 500 errors by email.

`MANAGERS` saranno notificati riguardo agli errori 404. `IGNORABLE_404_URLS` può aiutare a filtrare report spuri.

Vedi Come gestire il report degli errori per dettagli sul report degli errori via email.

La segnalazione degli errori via email non scala molto bene

Considera di usare un sistema di monitoraggio degli errori come Sentry, prima che la tua inbox sia inondata da errori. Sentry può anche aggregare i log.

### Personalizza la vista degli errori di default

Django include viste e template per molti codici di errore HTTP. Potresti voler fare override dei template creando i seguenti templati nella directory radice dei template: 404.html`, `500.html`, `403.html` e``400.html``. Le viste predefinite di errore dovrebbero essere sufficienti per il 99% delle applicazioni ma le puoi anche customize them .