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!
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.
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 .