Checklista för driftsättning¶
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.
Django 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.
Prestandaoptimeringar ä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.
Följande checklista innehåller inställningar som:
må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.
Kör manage.py check --deploy¶
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.
Byt bort från manage.py runserver¶
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.
Kritiska inställningar¶
:inställning:`SECRET_KEY`¶
**Den hemliga nyckeln måste vara ett stort slumpmässigt värde och den måste hållas hemlig
Se 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.
Istället för att hårdkoda den hemliga nyckeln i din inställningsmodul kan du ladda den från en miljövariabel:
import os
SECRET_KEY = os.environ["SECRET_KEY"]
eller från en fil:
with open("/etc/secret_key.txt") as f:
SECRET_KEY = f.read().strip()
Om du roterar hemliga nycklar kan du använda SECRET_KEY_FALLBACKS:
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
Se till att gamla hemliga nycklar tas bort från SECRET_KEY_FALLBACKS i god tid.
:inställning:`DEBUG`¶
**Du får aldrig aktivera debug i produktion
Du 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.
Miljöspecifika inställningar¶
:inställning:`ALLOWED_HOSTS`¶
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:
server {
listen 80 default_server;
return 444;
}
:inställning:`CACHES`¶
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.
Cacheservrar har ofta svag autentisering. Se till att de bara accepterar anslutningar från dina applikationsservrar.
:inställning:`DATABASER`¶
Parametrarna för databasanslutningen är förmodligen olika i utvecklings- och produktionsfasen.
Databaslö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.
Om du inte har skapat säkerhetskopior för din databas ska du göra det nu!
STATIC_ROOT och STATIC_URL¶
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.
:inställning:`MEDIA_ROOT` och :inställning:`MEDIA_URL`¶
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.
HTTPS¶
Alla 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)
Att 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.
När du har ställt in HTTPS aktiverar du följande inställningar.
Optimering av prestanda¶
Inställning DEBUG = False inaktiverar flera funktioner som bara är användbara under utveckling. Dessutom kan du justera följande inställningar.
Sessioner¶
Överväg att använda cachade sessioner för att förbättra prestandan.
Om du använder databaserade sessioner bör du regelbundet rensa gamla sessioner för att undvika att onödiga data lagras.
:inställning:`CONN_MAX_AGE`¶
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.
Detta är till stor hjälp på virtualiserade värdar med begränsad nätverksprestanda.
:inställning:`TEMPLATES`¶
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.
Felrapportering¶
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.
:inställning:`LOGGING`¶
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.
Se Loggning för mer information om loggning.
ADMINS och MANAGERS¶
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.
Felrapportering via e-post skalar inte särskilt bra
Överväg att använda ett felövervakningssystem som Sentry innan din inkorg översvämmas av rapporter. Sentry kan också samla ihop loggar.
Anpassa standardvyerna för fel¶
Django 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 :ref:``standardfelvyer <error-views>` som använder dessa mallar bör räcka för 99% of webbapplikationer, men du kan :ref:``anpassa dem <customizing-error-views>` också.
