Internet är en fientlig miljö. Innan du distribuerar ditt Django-projekt bör du ta dig tid att se över dina inställningar, med tanke på säkerhet, prestanda och drift.
\nDjango innehåller många säkerhetsfunktioner. Vissa är inbyggda och alltid aktiverade. Andra är valfria eftersom de inte alltid är lämpliga eller för att de är obekväma för utveckling. Att till exempel tvinga fram HTTPS kanske inte är lämpligt för alla webbplatser, och det är opraktiskt för lokal utveckling.
\nPrestandaoptimeringar är en annan kategori av kompromisser med bekvämlighet. Cachelagring är till exempel användbart i produktion, men mindre användbart för lokal utveckling. Behoven av felrapportering skiljer sig också mycket åt.
\nFöljande checklista innehåller inställningar som:
\nmåste vara korrekt inställd för att Django ska kunna tillhandahålla den förväntade säkerhetsnivån;
förväntas vara olika i varje miljö;
aktivera valfria säkerhetsfunktioner;
möjliggöra prestandaoptimeringar;
tillhandahålla felrapportering.
Många av dessa inställningar är känsliga och bör behandlas konfidentiellt. Om du släpper källkoden för ditt projekt är det vanligt att du publicerar lämpliga inställningar för utveckling och använder en privat inställningsmodul för produktion.
\nmanage.py check --deployLink to this heading#Vissa av de kontroller som beskrivs nedan kan automatiseras med hjälp av alternativet check --deploy. Var noga med att köra den mot din produktionsinställningsfil enligt beskrivningen i alternativets dokumentation.
manage.py runserverLink to this heading#Kommandot runserver är inte utformat för en produktionsmiljö. Var noga med att byta till en produktionsklar WSGI- eller ASGI-server. För några vanliga alternativ, se WSGI-servrar eller ASGI-servrar.
SECRET_KEYLink to this heading#**Den hemliga nyckeln måste vara ett stort slumpmässigt värde och den måste hållas hemlig
\nSe till att den nyckel som används i produktionen inte används någon annanstans och undvik att lägga den i källkontrollen. Detta minskar antalet vektorer från vilka en angripare kan få tag på nyckeln.
\nIstället för att hårdkoda den hemliga nyckeln i din inställningsmodul kan du ladda den från en miljövariabel:
\nimport os\n\nSECRET_KEY = os.environ["SECRET_KEY"]\neller från en fil:
\nwith open("/etc/secret_key.txt") as f:\n SECRET_KEY = f.read().strip()\nOm du roterar hemliga nycklar kan du använda SECRET_KEY_FALLBACKS:
import os\n\nSECRET_KEY = os.environ["CURRENT_SECRET_KEY"]\nSECRET_KEY_FALLBACKS = [\n os.environ["OLD_SECRET_KEY"],\n]\nSe till att gamla hemliga nycklar tas bort från SECRET_KEY_FALLBACKS i god tid.
DEBUGLink to this heading#**Du får aldrig aktivera debug i produktion
\nDu utvecklar säkert ditt projekt med DEBUG = True, eftersom detta möjliggör praktiska funktioner som fullständiga spårningar i din webbläsare.
För en produktionsmiljö är detta dock en riktigt dålig idé, eftersom det läcker ut massor av information om ditt projekt: utdrag ur källkoden, lokala variabler, inställningar, bibliotek som används osv.
\nALLOWED_HOSTSLink to this heading#När DEBUG = False, fungerar inte Django alls utan ett lämpligt värde för ALLOWED_HOSTS.
Denna inställning krävs för att skydda din webbplats mot vissa CSRF-attacker. Om du använder ett jokertecken måste du utföra en egen validering av HTTP-headern Host eller på annat sätt säkerställa att du inte är sårbar för denna typ av attacker.
Du bör också konfigurera webbservern som sitter framför Django för att validera värden. Den bör svara med en statisk felsida eller ignorera förfrågningar om felaktiga värdar istället för att vidarebefordra förfrågan till Django. På så sätt undviker du falska fel i dina Django-loggar (eller e-postmeddelanden om du har felrapportering konfigurerad på det sättet). På nginx kan du till exempel ställa in en standardserver för att returnera ”444 No Response” på en okänd värd:
\nserver {\n listen 80 default_server;\n return 444;\n}\nCACHESLink to this heading#Om du använder en cache kan anslutningsparametrarna vara olika i utveckling och i produktion. Django använder som standard lokal minnescachning per process, vilket kanske inte är önskvärt.
\nCacheservrar har ofta svag autentisering. Se till att de bara accepterar anslutningar från dina applikationsservrar.
\nDATABASESLink to this heading#Parametrarna för databasanslutningen är förmodligen olika i utvecklings- och produktionsfasen.
\nDatabaslösenord är mycket känsliga. Du bör skydda dem på exakt samma sätt som SECRET_KEY.
För maximal säkerhet bör du se till att databasservrarna endast accepterar anslutningar från dina applikationsservrar.
\nOm du inte har skapat säkerhetskopior för din databas ska du göra det nu!
\nSTATIC_ROOT och STATIC_URLLink to this heading#Statiska filer serveras automatiskt av utvecklingsservern. I produktion måste du definiera en STATIC_ROOT-katalog där collectstatic kommer att kopiera dem.
Se Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS) för mer information.
\nMEDIA_ROOT och MEDIA_URLLink to this heading#Mediefiler laddas upp av dina användare. De är inte pålitliga! Se till att din webbserver aldrig försöker tolka dem. Om en användare t.ex. laddar upp en .php-fil ska webbservern inte köra den.
Nu är det ett bra tillfälle att kontrollera din backup-strategi för dessa filer.
\nAlla webbplatser som tillåter användare att logga in bör tillämpa HTTPS på hela webbplatsen för att undvika att skicka access-tokens i klartext. I Django inkluderar access tokens inloggning/lösenord, sessionscookien och lösenordsåterställningstoken (du kan inte göra mycket för att skydda lösenordsåterställningstoken om du skickar dem via e-post)
\nAtt skydda känsliga områden som användarkontot eller administratören är inte tillräckligt, eftersom samma sessionskaka används för HTTP och HTTPS. Din webbserver måste omdirigera all HTTP-trafik till HTTPS och endast överföra HTTPS-förfrågningar till Django.
\nNär du har ställt in HTTPS aktiverar du följande inställningar.
\n\n\nInställning DEBUG = False inaktiverar flera funktioner som bara är användbara under utveckling. Dessutom kan du justera följande inställningar.
Överväg att använda cachade sessioner för att förbättra prestandan.
\nOm du använder databaserade sessioner bör du regelbundet rensa gamla sessioner för att undvika att onödiga data lagras.
\nCONN_MAX_AGELink to this heading#Om du aktiverar persistent database connections kan det resultera i en trevlig hastighetshöjning när anslutningen till databasen står för en betydande del av bearbetningstiden för begäran.
\nDetta är till stor hjälp på virtualiserade värdar med begränsad nätverksprestanda.
\nTEMPLATESLink to this heading#Om du aktiverar den cachade mallladdaren förbättras prestandan ofta drastiskt, eftersom du slipper kompilera varje mall varje gång den ska renderas. När DEBUG = False, aktiveras den cachade mallladdaren automatiskt. Se django.template.loaders.cached.Loader för mer information.
När du väl skickar din kod till produktion är den förhoppningsvis robust, men du kan inte utesluta oväntade fel. Tack och lov kan Django fånga upp fel och meddela dig om detta.
\nLOGGINGLink to this heading#Se över din loggningskonfiguration innan du sätter din webbplats i produktion och kontrollera att den fungerar som förväntat så snart du har fått lite trafik.
\nSe Loggning för mer information om loggning.
\nADMINS och MANAGERSLink to this heading#ADMINS kommer att meddelas om 500 fel via e-post.
MANAGERS kommer att meddelas om 404-fel. IGNORABLE_404_URLS kan hjälpa till att filtrera bort felaktiga rapporter.
Se Hur man hanterar felrapportering för mer information om felrapportering via e-post.
\n\nDjango innehåller standardvyer och mallar för flera HTTP-felkoder. Du kanske vill åsidosätta standardmallarna genom att skapa följande mallar i din rotmallkatalog: 404.html, 500.html, 403.html och 400.html. De standardfelvyer som använder dessa mallar bör räcka för 99% of webbapplikationer, men du kan anpassa dem också.