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.
\nDjango 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.
\nLe 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.
\nLa seguente lista di controlli include configurazioni come:
\ndevono 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.
\nmanage.py check --deployLink to this heading#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.
manage.py runserverLink to this heading#The runserver command is not designed for a production setting. Be\nsure to switch to a production-ready WSGI or ASGI server. For a few common\noptions, see WSGI servers or\nASGI servers.
SECRET_KEYLink to this heading#La chiave segreta deve essere un valore casuale grande e deve essere tenuta segreta.
\nAssicurati 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.
\nInvece di fare hardcoding della chiave segreta nelle tuo modulo di impostazioni, cosidera di caricarla da una variabile d’ambiente:
\nimport os\n\nSECRET_KEY = os.environ["SECRET_KEY"]\no da un file:
\nwith open("/etc/secret_key.txt") as f:\n SECRET_KEY = f.read().strip()\nSe stai utilizzando la rotazione delle chiavi per i segreti, puoi usare SECRET_KEY_FALLBACKS:
import os\n\nSECRET_KEY = os.environ["CURRENT_SECRET_KEY"]\nSECRET_KEY_FALLBACKS = [\n os.environ["OLD_SECRET_KEY"],\n]\nAssicurati che le vecchie chiavi siano rimosse prontamente da SECRET_KEY_FALLBACKS.
DEBUGLink to this heading#Non devi mai abilitare la modalità debug in produzione
\nStai 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…
\nALLOWED_HOSTSLink to this heading#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:
\nserver {\n listen 80 default_server;\n return 444;\n}\nCACHESLink to this heading#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.
\nI server di cache spesso hanno una autenticazione debole. Accertati che accettino connessioni solo dai server delle applicazioni.
\nDATABASESLink to this heading#I parametri di connessione al database saranno probabilmente differenti tra sviluppo e produzione.
\nLe 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.
\nSe non hai configurato i backup per il tuo database, fallo immediatamente!
\nSTATIC_ROOT and STATIC_URLLink to this heading#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.
\nMEDIA_ROOT e MEDIA_URLLink to this heading#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.
\nOgni 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).
\nProteggere 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.
\nQuando hai disposto HTTPS, abilita le seguenti impostazioni.
\n\n\nImpostare DEBUG = False disabilita molte feature che sono utili solo in fase di sviluppo. Inoltre, puoi mettere a punto le seguenti impostazioni.
Considera di usare cached sessions per migliorare la performance.
\nSe usi le sessioni su database, pulisci le vecchie sessioni regolarmente per evitare di memorizzare dati non necessari.
\nCONN_MAX_AGELink to this heading#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.
\nQuesto aiuta molto su virtual host con prestazioni di rete limitate.
\nTEMPLATESLink to this heading#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.
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.
\nLOGGINGLink to this heading#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.
\nVedi Logging per dettagli sul logging.
\nADMINS e MANAGERSLink to this heading#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.
\n\nDjango 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 .