Inställningar¶

Varning

Var försiktig när du åsidosätter inställningar, särskilt när standardvärdet är en icke-tom lista eller en ordbok, till exempel STATICFILES_FINDERS. Se till att du behåller de komponenter som krävs av de funktioner i Django som du vill använda.

Kärninställningar ¶

Här är en lista över inställningar som är tillgängliga i Django core och deras standardvärden. Inställningar som tillhandahålls av Contrib-appar listas nedan, följt av ett topiskt index över kärninställningarna. För introduktionsmaterial, se inställningar ämnesguide.

`ABSOLUTE_URL_OVERRIDES`¶

Standard: {} (Tom ordbok)

En ordbok som mappar strängarna "app_label.model_name" till funktioner som tar ett modellobjekt och returnerar dess URL. Detta är ett sätt att infoga eller åsidosätta get_absolute_url()-metoder per installation. Exempel:

ABSOLUTE_URL_OVERRIDES = {
    "blogs.blog": lambda o: "/blogs/%s/" % o.slug,
    "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

Modellnamnet som används i den här inställningen ska vara gemener, oavsett vad som gäller för det faktiska modellklassnamnet.

`ADMINS`¶

Standard: [] (tom lista)

En lista över alla personer som får meddelanden om kodfel. När DEBUG=False och AdminEmailHandler är konfigurerad i LOGGING (görs som standard), skickar Django e-post till dessa personer med detaljer om undantag som uppstått i begäran/svar-cykeln.

Varje objekt i listan ska vara en tupel av (Fullständigt namn, e-postadress). Exempel:

[("John", "john@example.com"), ("Mary", "mary@example.com")]

`TILLÅTNA_HOSTS`¶

Standard: [] (tom lista)

En lista med strängar som representerar de värd-/domännamn som denna Django-webbplats kan betjäna. Detta är en säkerhetsåtgärd för att förhindra HTTP Host header attacks, som är möjliga även under många till synes säkra webbserverkonfigurationer.

Värdena i listan kan vara fullständigt kvalificerade namn (t.ex. 'www.example.com'), i vilket fall de kommer att matchas mot begärans Host-huvud exakt (skiftlägesokänsligt, inkluderar inte port). Ett värde som börjar med en punkt kan användas som ett jokertecken för underdomäner: '.example.com' kommer att matcha example.com, www.example.com och alla andra underdomäner till example.com. Ett värde på '*' kommer att matcha vad som helst; i detta fall är du ansvarig för att tillhandahålla din egen validering av Host-huvudet (kanske i en mellanvara; i så fall måste denna mellanvara listas först i MIDDLEWARE).

Django tillåter också fullständigt kvalificerat domännamn (FQDN) för alla poster. Vissa webbläsare inkluderar en efterföljande punkt i Host-headern som Django tar bort när de utför värdvalidering.

Om rubriken Host (eller X-Forwarded-Host om USE_X_FORWARDED_HOST` är aktiverad) inte matchar något värde i den här listan, kommer metoden django.http.HttpRequest.get_host()`() att ge upphov till SuspiciousOperation.

När DEBUG är True och ALLOWED_HOSTS är tomt valideras värdena mot ['.localhost'', '127.0.0.1'', '[::1]'].

ALLOWED_HOSTS är också kontrollerad när tester körs.

Denna validering gäller endast via get_host(); om din kod kommer åt Host-rubriken direkt från request.META kringgår du detta säkerhetsskydd.

`TILLÄGG_SLASH`¶

Standard: True

Om URL:en för begäran inte matchar något av mönstren i URLconf och inte slutar med ett snedstreck, utfärdas en HTTP-omdirigering till samma URL med ett snedstreck tillagt, när värdet är satt till ”True”. Observera att omdirigeringen kan leda till att data som skickats i en POST-begäran går förlorade.

Inställningen APPEND_SLASH används endast om CommonMiddleware är installerad (se Middleware). Se även PREPEND_WWW.

`CACHES`¶

Standard:

{
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
    }
}

En ordbok som innehåller inställningarna för alla cacher som ska användas med Django. Det är en nästlad ordbok vars innehåll mappar cache-alias till en ordbok som innehåller alternativen för en enskild cache.

Inställningen CACHES måste konfigurera en standard-cache; ett valfritt antal ytterligare cacher kan också anges. Om du använder en annan cache-backend än den lokala minnescachen, eller om du behöver definiera flera cacheminnen, krävs andra alternativ. Följande cache-alternativ finns tillgängliga.

`BACKEND`¶

Standard: '' (tom sträng)

Den cache-backend som ska användas. De inbyggda cache-backendarna är:

'django.core.cache.backends.db.DatabaseCache'`
'django.core.cache.backends.dummy.DummyCache'`
'django.core.cache.backends.filebased.FileBasedCache'`
'django.core.cache.backends.locmem.LocMemCache'`
'django.core.cache.backends.memcached.PyMemcacheCache'`
'django.core.cache.backends.memcached.PyLibMCCache'`
'django.core.cache.backends.redis.RedisCache'`

Du kan använda en cache-backend som inte levereras med Django genom att ställa in BACKEND till en fullt kvalificerad sökväg för en cache-backend-klass (t.ex. mypackage.backends.whatever.WhateverCache).

`NYCKEL_FUNKTION`¶

En sträng som innehåller en prickad sökväg till en funktion (eller en anropsbar funktion) som definierar hur ett prefix, en version och en nyckel ska sättas samman till en slutlig cache-nyckel. Standardimplementeringen är likvärdig med funktionen:

def make_key(key, key_prefix, version):
    return ":".join([key_prefix, str(version), key])

Du kan använda vilken nyckelfunktion du vill, så länge den har samma argumentsignatur.

Se cache-dokumentationen för mer information.

`KEY_PREFIX`¶

Standard: '' (tom sträng)

En sträng som automatiskt kommer att inkluderas (prepended som standard) i alla cache-nycklar som används av Django-servern.

Se cache-dokumentationen för mer information.

`LOCATION`¶

Standard: '' (tom sträng)

Platsen för den cache som ska användas. Det kan vara en katalog för en filsystemcache, en värd och port för en memcache-server eller ett identifierande namn för en lokal minnescache. t.ex.:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}

`OPTIONS`¶

Standard: None

Extra parametrar att skicka till cache-backend. Tillgängliga parametrar varierar beroende på din cache-backend.

En del information om tillgängliga parametrar finns i cache arguments-dokumentationen. Mer information finns i dokumentationen för din backend-modul.

`TIMEOUT`¶

Standard: 300

Antalet sekunder innan en cache-post anses vara inaktuell. Om värdet på denna inställning är None kommer cache-poster inte att förfalla. Ett värde på 0 gör att nycklar omedelbart upphör att gälla (i praktiken ”inte cache”).

`VERSION`¶

Standard: 1

Standardversionsnummer för cache-nycklar som genereras av Django-servern.

Se cache-dokumentationen för mer information.

`CACHE_MIDDLEWARE_ALIAS`¶

Standard: 'default'

Den cacheanslutning som ska användas för cache middleware.

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

Standard: '' (tom sträng)

En sträng som kommer att prefixeras till cacheknapparna som genereras av cache middleware. Detta prefix kombineras med inställningen KEY_PREFIX; det ersätter den inte.

Se Djangos ramverk för cache.

`CACHE_MIDDLEWARE_SEKUNDER`¶

Standard: 600

Standard heltal antal sekunder för att cachelagra en sida för cache middleware.

Se Djangos ramverk för cache.

`CSRF_USE_SESSIONS`¶

Standard: False

Om CSRF-token ska lagras i användarens session i stället för i en cookie. Det kräver användning av django.contrib.sessions.

Att lagra CSRF-token i en cookie (Djangos standard) är säkert, men att lagra den i sessionen är vanligt i andra webbramverk och därför ibland ett krav från säkerhetsrevisorer.

Eftersom :ref:standardfelvyer <error-views> kräver CSRF-token måste SessionMiddleware` visas i MIDDLEWARE` före alla middleware som kan ge upphov till ett undantag för att utlösa en felvy (t.ex. PermissionDenied`) om du använder CSRF_USE_SESSIONS. Se Beställning av mellanprogramvara.

`CSRF_FAILURE_VIEW`¶

Standard: 'django.views.csrf.csrf_failure' ``

En prickad sökväg till den vyfunktion som ska användas när en inkommande begäran avvisas av CSRF-skydd. Funktionen bör ha denna signatur:

def csrf_failure(request, reason=""): ...

där reason är ett kort meddelande (avsett för utvecklare eller loggning, inte för slutanvändare) som anger orsaken till att begäran avvisades. Den bör returnera en HttpResponseForbidden.

django.views.csrf.csrf_failure() accepterar en ytterligare parameter template_name som standard är '403_csrf.html'. Om det finns en mall med det namnet kommer den att användas för att rendera sidan.

`CSRF_HEADER_NAME`¶

Standard: 'HTTP_X_CSRFTOKEN'`

Namnet på det förfrågningshuvud som används för CSRF-autentisering.

Som med andra HTTP-rubriker i request.META normaliseras rubriknamnet som tas emot från servern genom att konvertera alla tecken till versaler, ersätta eventuella bindestreck med understreck och lägga till ett 'HTTP_'-prefix till namnet. Om klienten t.ex. skickar ett 'X-XSRF-TOKEN'-huvud, bör inställningen vara 'HTTP_X_XSRF_TOKEN'.

`CSRF_TRUSTED_ORIGINS`¶

Standard: [] (tom lista)

En lista över betrodda ursprung för osäkra förfrågningar (t.ex. POST).

För förfrågningar som innehåller rubriken Origin kräver Djangos CSRF-skydd att rubriken matchar det ursprung som finns i rubriken Host.

För en secure osäker begäran som inte innehåller rubriken Origin måste begäran ha en rubrik Referer som matchar det ursprung som finns i rubriken Host.

Dessa kontroller förhindrar t.ex. att en POST-förfrågan från subdomain.example.com lyckas mot api.example.com. Om du behöver osäkra förfrågningar över ursprungsgränserna och fortsätter med exemplet, lägg till 'https://subdomain.example.com' i den här listan (och/eller http://... om förfrågningarna kommer från en osäker sida).

Inställningen stöder även underdomäner, så du kan t.ex. lägga till 'https://*.example.com för att tillåta åtkomst från alla underdomäner till example.com.

`DATABASER`¶

Standard: {} (Tom ordbok)

En ordbok som innehåller inställningarna för alla databaser som ska användas med Django. Det är en nästlad ordbok vars innehåll mappar ett databasalias till en ordbok som innehåller alternativen för en enskild databas.

Inställningen DATABASES måste konfigurera en ``standard``databas; ett valfritt antal ytterligare databaser kan också anges.

Den enklaste möjliga inställningsfilen är för en installation med en enda databas som använder SQLite. Detta kan konfigureras med hjälp av följande:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "mydatabase",
    }
}

Vid anslutning till andra databasbackends, t.ex. MariaDB, MySQL, Oracle eller PostgreSQL, krävs ytterligare anslutningsparametrar. Se inställningen ENGINE nedan om hur du anger andra databastyper. Detta exempel är för PostgreSQL:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "mydatabase",
        "USER": "mydatabaseuser",
        "PASSWORD": "mypassword",
        "HOST": "127.0.0.1",
        "PORT": "5432",
    }
}

Följande inre alternativ som kan behövas för mer komplexa konfigurationer finns tillgängliga:

`ATOMISKA_FÖRFRÅGNINGAR`¶

Standard: False

Sätt detta till True för att paketera varje vy i en transaktion på denna databas. Se Koppling av transaktioner till HTTP-förfrågningar.

`AUTOCOMMIT`¶

Standard: True

Sätt detta till False om du vill inaktivera Djangos transaktionshantering och implementera din egen.

`ENGINE`¶

Standard: '' (tom sträng)

Den databasbackend som ska användas. De inbyggda databasbackendarna är:

'django.db.backends.postgresql'`
'django.db.backends.mysql'`
'django.db.backends.sqlite3'`
'django.db.backends.oracle'`

Du kan använda en databasbackend som inte levereras med Django genom att ställa in ENGINE till en fullständigt kvalificerad sökväg (dvs. mypackage.backends.whatever).

`HOST`¶

Standard: '' (tom sträng)

Vilken värd som ska användas vid anslutning till databasen. En tom sträng betyder localhost. Används inte med SQLite.

Om det här värdet börjar med ett snedstreck ('/') och du använder MySQL, kommer MySQL att ansluta via en Unix-socket till den angivna sockeln. Till exempel:

"HOST": "/var/run/mysql"

Om du använder MySQL och det här värdet inte börjar med ett snedstreck, antas det här värdet vara värden.

Om du använder PostgreSQL, som standard (tom :inställning:`HOST`), görs anslutningen till databasen via UNIX-domänuttag (’lokala’ rader i pg_hba.conf). Om ditt UNIX-domänuttag inte finns på standardplatsen använder du samma värde för unix_socket_directory från postgresql.conf. Om du vill ansluta via TCP-sockets ska du ange HOST till ’localhost’ eller ’127.0.0.1’ (’host’-raderna i pg_hba.conf). På Windows bör du alltid definiera HOST, eftersom UNIX-domänuttag inte är tillgängliga.

`NAME`¶

Standard: '' (tom sträng)

Namnet på den databas som ska användas. För SQLite är det den fullständiga sökvägen till databasfilen. När du anger sökvägen ska du alltid använda snedstreck, även i Windows (t.ex. C:/homes/user/mysite/sqlite3.db).

`CONN_MAX_AGE`¶

Standard: 0

Livslängden för en databasanslutning, som ett heltal i sekunder. Använd 0 för att stänga databasanslutningar i slutet av varje begäran - Djangos historiska beteende - och None för obegränsad persistent databasanslutningar.

`CONN_HÄLSOKONTROLLER`¶

Standard: False

Om inställningen är True kommer befintliga :ref:persistent database connections <persistent-database-connections> att hälsokontrolleras innan de återanvänds i varje begäran om databasåtkomst. Om hälsokontrollen misslyckas kommer anslutningen att återupprättas utan att begäran misslyckas när anslutningen inte längre är användbar men databasservern är redo att acceptera och betjäna nya anslutningar (t.ex. efter omstart av databasservern som stänger befintliga anslutningar).

`OPTIONS`¶

Standard: {} (Tom ordbok)

Extra parametrar som ska användas vid anslutning till databasen. Tillgängliga parametrar varierar beroende på databasens backend.

En del information om tillgängliga parametrar finns i dokumentationen Database Backends. För mer information, se din backendmoduls egen dokumentation.

`PASSWORD`¶

Standard: '' (tom sträng)

Det lösenord som ska användas vid anslutning till databasen. Används inte med SQLite.

`PORT`¶

Standard: '' (tom sträng)

Den port som ska användas vid anslutning till databasen. En tom sträng innebär standardporten. Används inte med SQLite.

`TIME_ZONE`¶

Standard: None

En sträng som representerar tidszonen för denna databasanslutning eller None. Detta inre alternativ till inställningen DATABASES accepterar samma värden som den allmänna inställningen TIME_ZONE.

När USE_TZ är True, returnerar läsning av datatider från databasen medvetna datatider med tidszonen inställd på detta alternativs värde om det inte är None, eller på UTC annars.

När USE_TZ är False, är det fel att ange detta alternativ.

Om databasens backend inte stöder tidszoner (t.ex. SQLite, MySQL, Oracle), läser och skriver Django datatider i lokal tid enligt detta alternativ om det är inställt och i UTC om det inte är det.

Om du ändrar tidszonen för anslutningen ändras hur datatider läses från och skrivs till databasen.
- Om Django hanterar databasen och du inte har någon stark anledning att göra något annat, bör du lämna detta alternativ oinställt. Det är bäst att lagra datatider i UTC eftersom det undviker tvetydiga eller obefintliga datatider under sommartidsändringar. Att ta emot datatider i UTC håller också aritmetiken för datatider enkel - det finns inget behov av att överväga potentiella offsetförändringar under en övergång till sommartid.
- Om du ansluter till en databas från tredje part som lagrar datatider i lokal tid snarare än UTC, måste du ställa in det här alternativet till lämplig tidszon. På samma sätt, om Django hanterar databasen men tredjepartssystem ansluter till samma databas och förväntar sig att hitta datatider i lokal tid, måste du ställa in det här alternativet.
Om databasens backend stöder tidszoner (t.ex. PostgreSQL), ställs databasanslutningens tidszon in på detta värde.

Även om inställningen av alternativet TIME_ZONE mycket sällan behövs, finns det situationer där det blir nödvändigt. Specifikt rekommenderas att matcha den allmänna inställningen TIME_ZONE när du hanterar råa frågor som involverar datum / tidsfunktioner som PostgreSQLs `` date_trunc() `` eller `` generate_series() ``, särskilt när du genererar tidsbaserade serier som övergår dagsljusbesparingar.

Detta värde kan ändras när som helst, databasen kommer att hantera konverteringen av datatider till den konfigurerade tidszonen.

Detta har dock en nackdel: att ta emot alla datatider i lokal tid gör datatidsaritmetik mer knepigt - du måste ta hänsyn till eventuella offsetändringar under DST-övergångar.

Överväg att konvertera till lokal tid uttryckligen med AT TIME ZONE i råa SQL-frågor istället för att ange alternativet TIME_ZONE.

`AVAKTIVERA_SERVER_SIDE_CURSORS`¶

Standard: False

Ställ in detta på True om du vill inaktivera användningen av server-side cursors med QuerySet.iterator(). Transaktionspoolning och cursorer på serversidan beskriver användningsfallet.

Detta är en PostgreSQL-specifik inställning.

`USER`¶

Standard: '' (tom sträng)

Det användarnamn som ska användas vid anslutning till databasen. Används inte med SQLite.

`TEST`¶

Standard: {} (Tom ordbok)

En ordbok med inställningar för testdatabaser; för mer information om hur testdatabaser skapas och används, se Testdatabasen.

Här är ett exempel med en testdatabas-konfiguration:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "USER": "mydatabaseuser",
        "NAME": "mydatabase",
        "TEST": {
            "NAME": "mytestdatabase",
        },
    },
}

Följande nycklar i ordlistan TEST är tillgängliga:

`CHARSET`¶

Standard: None

Den teckenkodning som används för att skapa testdatabasen. Värdet på denna sträng skickas direkt till databasen, så dess format är backend-specifikt.

Stöds av PostgreSQL (postgresql) och MySQL (mysql) backends.

`KOLLATION`¶

Standard: None

Den sorteringsordning som ska användas när testdatabasen skapas. Detta värde skickas direkt till backend, så dess format är backend-specifikt.

Stöds endast för mysql backend (se MySQL manual för detaljer).

bEROENDEN¶

Standard: ['default'], för alla andra databaser än default, som inte har några beroenden.

Databasens beroenden i skapelseordningen. Se dokumentationen om kontrollera skapelseordningen för testdatabaser för mer information.

`MIGRATE`¶

Standard: True

När värdet är satt till False kommer migreringar inte att köras när testdatabasen skapas. Detta liknar inställningen av None som ett värde i MIGRATION_MODULES, men för alla appar.

`MIRROR`¶

Standard: None

Aliaset för den databas som denna databas ska spegla under testning. Den är beroende av transaktioner och måste därför användas inom TransactionTestCase i stället för TestCase.

Den här inställningen finns för att möjliggöra testning av primär/replika (kallas master/slave av vissa databaser) konfigurationer av flera databaser. Mer information finns i dokumentationen om testing primary/replica configurations.

`NAME`¶

Standard: None

Namnet på den databas som ska användas när testsviten körs.

Om standardvärdet (None) används med SQLite-databasmotorn kommer testerna att använda en minnesbaserad databas. För alla andra databasmotorer kommer testdatabasen att använda namnet 'test_' + DATABASE_NAME.

Se testdatabasen.

`TEMPLATE`¶

Detta är en PostgreSQL-specifik inställning.

Namnet på en template (t.ex. 'template0') från vilken testdatabasen ska skapas.