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.
\nABSOLUTE_URL_OVERRIDESLink to this heading#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 = {\n "blogs.blog": lambda o: "/blogs/%s/" % o.slug,\n "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),\n}\nModellnamnet som används i den här inställningen ska vara gemener, oavsett vad som gäller för det faktiska modellklassnamnet.
\nADMINSLink to this heading#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:
\n[("John", "john@example.com"), ("Mary", "mary@example.com")]\nTILLÅTNA_HOSTSLink to this heading#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.
\nVä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_SLASHLink to this heading#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.
\nInställningen APPEND_SLASH används endast om CommonMiddleware är installerad (se Middleware). Se även PREPEND_WWW.
CACHESLink to this heading#Standard:
\n{\n "default": {\n "BACKEND": "django.core.cache.backends.locmem.LocMemCache",\n }\n}\nEn 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.
\nInstä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.
BACKENDLink to this heading#Standard: '' (tom sträng)
Den cache-backend som ska användas. De inbyggda cache-backendarna är:
\n'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_FUNKTIONLink to this heading#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:
\ndef make_key(key, key_prefix, version):\n return ":".join([key_prefix, str(version), key])\nDu kan använda vilken nyckelfunktion du vill, så länge den har samma argumentsignatur.
\nSe cache-dokumentationen för mer information.
\nKEY_PREFIXLink to this heading#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.
\nSe cache-dokumentationen för mer information.
\nLOCATIONLink to this heading#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.:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n }\n}\nOPTIONSLink to this heading#Standard: None
Extra parametrar att skicka till cache-backend. Tillgängliga parametrar varierar beroende på din cache-backend.
\nEn del information om tillgängliga parametrar finns i cache arguments-dokumentationen. Mer information finns i dokumentationen för din backend-modul.
\nTIMEOUTLink to this heading#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”).
VERSIONLink to this heading#Standard: 1
Standardversionsnummer för cache-nycklar som genereras av Django-servern.
\nSe cache-dokumentationen för mer information.
\nCACHE_MIDDLEWARE_ALIASLink to this heading#Standard: 'default'
Den cacheanslutning som ska användas för cache middleware.
\nCACHE_MIDDLEWARE_KEY_PREFIXLink to this heading#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.
CACHE_MIDDLEWARE_SEKUNDERLink to this heading#Standard: 600
Standard heltal antal sekunder för att cachelagra en sida för cache middleware.
\n\nCSRF_USE_SESSIONSLink to this heading#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.
\nEftersom standardfelvyer 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_VIEWLink to this heading#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:
\ndef csrf_failure(request, reason=""): ...\ndä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_NAMELink to this heading#Standard: 'HTTP_X_CSRFTOKEN'
Namnet på det förfrågningshuvud som används för CSRF-autentisering.
\nSom 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_ORIGINSLink to this heading#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.
DATABASERLink to this heading#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.
\nInstä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:
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.sqlite3",\n "NAME": "mydatabase",\n }\n}\nVid 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 = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "NAME": "mydatabase",\n "USER": "mydatabaseuser",\n "PASSWORD": "mypassword",\n "HOST": "127.0.0.1",\n "PORT": "5432",\n }\n}\nFöljande inre alternativ som kan behövas för mer komplexa konfigurationer finns tillgängliga:
\nATOMISKA_FÖRFRÅGNINGARLink to this heading#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.
AUTOCOMMITLink to this heading#Standard: True
Sätt detta till False om du vill inaktivera Djangos transaktionshantering och implementera din egen.
ENGINELink to this heading#Standard: '' (tom sträng)
Den databasbackend som ska användas. De inbyggda databasbackendarna är:
\n'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).
HOSTLink to this heading#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.
\nOm 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"\nOm 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.
\nOm du använder PostgreSQL, som standard (tom 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.
NAMELink to this heading#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_AGELink to this heading#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ÄLSOKONTROLLERLink to this heading#Standard: False
Om inställningen är True kommer befintliga 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).
OPTIONSLink to this heading#Standard: {} (Tom ordbok)
Extra parametrar som ska användas vid anslutning till databasen. Tillgängliga parametrar varierar beroende på databasens backend.
\nEn del information om tillgängliga parametrar finns i dokumentationen Database Backends. För mer information, se din backendmoduls egen dokumentation.
\nPASSWORDLink to this heading#Standard: '' (tom sträng)
Det lösenord som ska användas vid anslutning till databasen. Används inte med SQLite.
\nPORTLink to this heading#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.
\nTIME_ZONELink to this heading#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.
\nOm du ändrar tidszonen för anslutningen ändras hur datatider läses från och skrivs till databasen.
\nOm 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.
\nÄ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.
\nDetta 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.
\nÖ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_CURSORSLink to this heading#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.
\nUSERLink to this heading#Standard: '' (tom sträng)
Det användarnamn som ska användas vid anslutning till databasen. Används inte med SQLite.
\nTESTLink to this heading#Standard: {} (Tom ordbok)
En ordbok med inställningar för testdatabaser; för mer information om hur testdatabaser skapas och används, se Testdatabasen.
\nHär är ett exempel med en testdatabas-konfiguration:
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "USER": "mydatabaseuser",\n "NAME": "mydatabase",\n "TEST": {\n "NAME": "mytestdatabase",\n },\n },\n}\nFöljande nycklar i ordlistan TEST är tillgängliga:
CHARSETLink to this heading#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.
\nStöds av PostgreSQL (postgresql) och MySQL (mysql) backends.
KOLLATIONLink to this heading#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.
\nStöds endast för mysql backend (se MySQL manual för detaljer).
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.
\nMIGRATELink to this heading#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.
MIRRORLink to this heading#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.
\nNAMELink to this heading#Standard: None
Namnet på den databas som ska användas när testsviten körs.
\nOm 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.
\nTEMPLATELink to this heading#Detta är en PostgreSQL-specifik inställning.
\nNamnet på en template (t.ex. 'template0') från vilken testdatabasen ska skapas.
CREATE_DBLink to this heading#Standard: True
Detta är en Oracle-specifik inställning.
\nOm den är inställd på False kommer test tablespaces inte att skapas automatiskt i början av testerna eller tas bort i slutet.
SKAPA_ANVÄNDARELink to this heading#Standard: True
Detta är en Oracle-specifik inställning.
\nOm den är inställd på False kommer testanvändaren inte att skapas automatiskt i början av testerna och tas bort i slutet.
USERLink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nAnvändarnamnet som ska användas vid anslutning till Oracle-databasen som kommer att användas när tester körs. Om det inte anges kommer Django att använda 'test_' + USER.
PASSWORDLink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nDet lösenord som ska användas vid anslutning till Oracle-databasen som kommer att användas när tester körs. Om det inte anges kommer Django att generera ett slumpmässigt lösenord.
\nORACLE_HANTERADE_FILERLink to this heading#Standard: False
Detta är en Oracle-specifik inställning.
\nOm inställningen är True kommer Oracle Managed Files (OMF) tablespaces att användas. DATAFILE och DATAFILE_TMP kommer att ignoreras.
TBLSPACELink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nNamnet på det tablespace som kommer att användas när tester körs. Om det inte anges kommer Django att använda 'test_' + USER.
TBLSPACE_TMPLink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nNamnet på det temporära tablespace som kommer att användas när tester körs. Om det inte anges kommer Django att använda 'test_' + USER + '_temp'.
DATAFILELink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nNamnet på datafilen som ska användas för TBLSPACE. Om det inte anges kommer Django att använda TBLSPACE + '.dbf'.
DATAFILE_TMPLink to this heading#Standard: None
Detta är en Oracle-specifik inställning.
\nNamnet på datafilen som ska användas för TBLSPACE_TMP. Om det inte anges kommer Django att använda TBLSPACE_TMP + '.dbf'.
DATAFIL_MAXSTORLEKLink to this heading#Standard: '500M'
Detta är en Oracle-specifik inställning.
\nDen maximala storlek som DATAFILE får växa till.
\nDATAFIL_TMP_MAXSTORLEKLink to this heading#Standard: '500M'
Detta är en Oracle-specifik inställning.
\nDen maximala storlek som DATAFILE_TMP får växa till.
\nDATAFIL_STORLEKLink to this heading#Standard: '50M'
Detta är en Oracle-specifik inställning.
\nDen ursprungliga storleken på DATAFILE.
\nDATAFIL_TMP_STORLEKLink to this heading#Standard: '50M'
Detta är en Oracle-specifik inställning.
\nDen ursprungliga storleken på DATAFILE_TMP.
\nDATAFIL_EXTSTORLEKLink to this heading#Standard: '25M'
Detta är en Oracle-specifik inställning.
\nDen mängd som DATAFILE utökas med när mer utrymme krävs.
\nDATAFIL_TMP_EXTSIZELink to this heading#Standard: '25M'
Detta är en Oracle-specifik inställning.
\nDet belopp med vilket DATAFILE_TMP utökas när mer utrymme krävs.
\nDATA_UPLOAD_MAX_MEMORY_SIZELink to this heading#Standard: 2621440 (dvs. 2,5 MB).
Den maximala storleken i byte som en request body får vara innan en SuspiciousOperation (RequestDataTooBig) uppstår. Kontrollen görs vid åtkomst till request.body eller request.POST och beräknas mot den totala storleken på begäran exklusive eventuella filuppladdningsdata. Du kan ställa in detta till None för att inaktivera kontrollen. Applikationer som förväntas ta emot ovanligt stora formulärposter bör justera den här inställningen.
Mängden data i begäran är korrelerad med mängden minne som behövs för att behandla begäran och fylla i GET- och POST-ordlistorna. Stora förfrågningar kan användas som en attackvektor för överbelastningsattacker om de lämnas okontrollerade. Eftersom webbservrar vanligtvis inte utför djupgående inspektion av förfrågningar är det inte möjligt att utföra en liknande kontroll på den nivån.
\nSe även FILE_UPLOAD_MAX_MEMORY_SIZE.
DATA_UPPLADDNING_MAX_ANTAL_FÄLTLink to this heading#Standard: 1000
Det maximala antalet parametrar som kan tas emot via GET eller POST innan en SuspiciousOperation (TooManyFields) utlöses. Du kan ställa in detta till None för att inaktivera kontrollen. Applikationer som förväntas ta emot ett ovanligt stort antal formulärfält bör justera denna inställning.
Antalet parametrar för begäran är korrelerat med den tid som krävs för att behandla begäran och fylla i GET- och POST-ordlistorna. Stora förfrågningar kan användas som en attackvektor för överbelastningsattacker om de lämnas okontrollerade. Eftersom webbservrar vanligtvis inte utför djupgående inspektion av förfrågningar är det inte möjligt att utföra en liknande kontroll på den nivån.
\nDATA_UPLOAD_MAX_NUMBER_FILESLink to this heading#Standard: 100
Det maximala antalet filer som kan tas emot via POST i en multipart/form-data-kodad begäran innan en SuspiciousOperation (TooManyFiles) utlöses. Du kan ställa in detta till None för att inaktivera kontrollen. Program som förväntas ta emot ett ovanligt stort antal filfält bör justera denna inställning.
Antalet accepterade filer är korrelerat med den tid och det minne som krävs för att behandla begäran. Stora förfrågningar kan användas som en attackvektor för överbelastningsattacker om de lämnas okontrollerade. Eftersom webbservrar vanligtvis inte utför djupgående inspektion av förfrågningar är det inte möjligt att utföra en liknande kontroll på den nivån.
\nDATABAS_ROUTRARLink to this heading#Standard: [] (tom lista)
Listan över routrar som används för att avgöra vilken databas som ska användas vid en databasfråga.
\nSe dokumentationen om automatisk databasrouting i konfigurationer med flera databaser.
\nDATUM_FORMATLink to this heading#Standard: 'N j, Y' (t.ex. Feb. 4, 2003)
Standardformateringen som ska användas för att visa datumfält i alla delar av systemet. Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället. Se tillåtna datumformatsträngar.
Se även DATETIME_FORMAT, TIME_FORMAT och SHORT_DATE_FORMAT.
DATUM_INMATNINGSFORMATLink to this heading#Standard:
\n[\n "%Y-%m-%d", # '2006-10-25'\n "%m/%d/%Y", # '10/25/2006'\n "%m/%d/%y", # '10/25/06'\n "%b %d %Y", # 'Oct 25 2006'\n "%b %d, %Y", # 'Oct 25, 2006'\n "%d %b %Y", # '25 Oct 2006'\n "%d %b, %Y", # '25 Oct, 2006'\n "%B %d %Y", # 'October 25 2006'\n "%B %d, %Y", # 'October 25, 2006'\n "%d %B %Y", # '25 October 2006'\n "%d %B, %Y", # '25 October, 2006'\n]\nEn lista över format som accepteras vid inmatning av data i ett datumfält. Formaten prövas i ordning och det första giltiga formatet används. Observera att dessa formatsträngar använder Pythons datetime-modulsyntax, inte formatsträngarna från date-mallfiltret.
Det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället.
\nSe även DATETIME_INPUT_FORMATS och TIME_INPUT_FORMATS.
DATATID_FORMATLink to this heading#Standard: 'N j, Y, P' (t.ex. 4 februari 2003, kl. 16.00)
Standardformateringen som ska användas för att visa datetime-fält i alla delar av systemet. Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället. Se tillåtna datumformatsträngar.
Se även DATE_FORMAT, TIME_FORMAT och SHORT_DATETIME_FORMAT.
DATATID_INMATNINGSFORMATLink to this heading#Standard:
\n[\n "%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59'\n "%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200'\n "%Y-%m-%d %H:%M", # '2006-10-25 14:30'\n "%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59'\n "%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200'\n "%m/%d/%Y %H:%M", # '10/25/2006 14:30'\n "%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59'\n "%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200'\n "%m/%d/%y %H:%M", # '10/25/06 14:30'\n]\nEn lista över format som accepteras vid inmatning av data i ett datetime-fält. Formaten prövas i ordning och det första giltiga formatet används. Observera att dessa formatsträngar använder Pythons datetime-modulsyntax, inte formatsträngarna från date-mallfiltret. Format som endast innehåller datum ingår inte eftersom datetime-fält automatiskt kommer att prova DATE_INPUT_FORMATS som sista utväg.
Det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället.
\nSe även DATE_INPUT_FORMATS och TIME_INPUT_FORMATS.
DEBUGLink to this heading#Standard: False
Ett boolean som aktiverar/avaktiverar felsökningsläget.
\nDriftsätt aldrig en webbplats i produktion med DEBUG aktiverad.
En av huvudfunktionerna i felsökningsläget är visningen av detaljerade felsidor. Om din app ger upphov till ett undantag när DEBUG är True, kommer Django att visa en detaljerad spårning, inklusive en hel del metadata om din miljö, till exempel alla de för närvarande definierade Django-inställningarna (från settings.py).
Som en säkerhetsåtgärd kommer Django inte att inkludera inställningar som kan vara känsliga, till exempel SECRET_KEY. Specifikt kommer det att utesluta alla inställningar vars namn innehåller något av följande:
'API'
'KEY'
'PASS'
”SECRET
'SIGNATUR'
'TOKEN'
Observera att detta är delvisa matchningar. 'PASS' kommer också att matcha PASSWORD, precis som 'TOKEN' också kommer att matcha TOKENIZED och så vidare.
Observera dock att det alltid kommer att finnas delar av din felsökningsutdata som är olämpliga för offentlig konsumtion. Filsökvägar, konfigurationsalternativ och liknande ger alla angripare extra information om din server.
\nDet är också viktigt att komma ihåg att när man kör med DEBUG påslagen, kommer Django att komma ihåg varje SQL-fråga som körs. Detta är användbart när du felsöker, men det kommer snabbt att förbruka minne på en produktionsserver.
Slutligen, om DEBUG är False, måste du också korrekt ställa in ALLOWED_HOSTS. Om du inte gör det kommer alla förfrågningar att returneras som ”Bad Request (400)”.
DEBUG_PROPAGATE_EXCEPTIONSLink to this heading#Standard: False
Om inställningen är True hoppas Djangos undantagshantering av vyfunktioner (handler500, eller debug-vyn om DEBUG är True) och loggning av 500-svar (django.begäran) över och undantag sprids uppåt.
Detta kan vara användbart för vissa testuppsättningar. Det bör inte användas på en live-webbplats om du inte vill att din webbserver (istället för Django) ska generera ”Internal Server Error”-svar. I så fall måste du se till att din server inte visar stackspårningen eller annan känslig information i svaret.
\nDECIMAL_SEPARATORLink to this heading#Standard: '.' (punkt)
Standard decimalavskiljare som används vid formatering av decimaltal.
\nObservera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas i stället.
\nSe även NUMBER_GROUPING, THOUSAND_SEPARATOR och USE_THOUSAND_SEPARATOR.
STANDARD_AUTO_FÄLTLink to this heading#Standard: 'django.db.models.AutoField` '
Standardfältstyp för primärnyckel som ska användas för modeller som inte har ett fält med primary_key=True.
STANDARD_TECKENSNITTLink to this heading#Standard: 'utf-8'
Standardteckensnitt som ska användas för alla HttpResponse-objekt, om ingen MIME-typ anges manuellt. Används när rubriken Content-Type konstrueras.
STANDARD_AVVIKELSE_RAPPORTÖRLink to this heading#Standard: 'django.views.debug.ExceptionReporter` '
Standardklass för undantagsrapportör som ska användas om ingen har tilldelats HttpRequest-instansen ännu. Se Anpassade felrapporter.
STANDARD_FILTER_FÖR_AVVIKELSERAPPORTÖRLink to this heading#Standard: 'django.views.debug.SafeExceptionReporterFilter` '
Standardfilterklass för undantagsrapporter som ska användas om ingen har tilldelats HttpRequest-instansen ännu. Se Filtrering av felrapporter.
STANDARD_FRÅN_EMAILLink to this heading#Standard: 'webmaster@localhost'
Standard-e-postadress för automatiserad korrespondens från webbplatsansvarig(a). Den här adressen används i rubriken From: i utgående e-postmeddelanden och kan ha vilket format som helst som är giltigt i det valda e-postprotokollet.
Detta påverkar inte felmeddelanden som skickas till ADMINS och MANAGERS. Se SERVER_EMAIL för detta.
STANDARD_INDEX_TABLESPACELink to this heading#Standard: '' (tom sträng)
Förvalt tablespace att använda för index på fält som inte anger något, om backend stöder det (se Bordsytor).
\nSTANDARD_TABELLUTRYMMELink to this heading#Standard: '' (tom sträng)
Standard tablespace att använda för modeller som inte anger något, om backend stöder det (se Bordsytor).
\nTILLÅTNA_ANVÄNDARE_AGENTERLink to this heading#Standard: [] (tom lista)
Lista över kompilerade objekt med reguljära uttryck som representerar User-Agent-strängar som inte får besöka någon sida i hela systemet. Använd detta för bots/crawlers. Detta används endast om CommonMiddleware är installerat (se Middleware).
EMAIL_BACKENDLink to this heading#Standard: 'django.core.mail.backends.smtp.EmailBackend` '
Den backend som ska användas för att skicka e-post. För en lista över tillgängliga backends se Backend för e-post.
\nEMAIL_FILE_PATHLink to this heading#Standard: Ej definierad
\nDen katalog som används av file email backend för att lagra utdatafiler.
\nEMAIL_HOSTLink to this heading#Standard: 'localhost'
Den värd som ska användas för att skicka e-post.
\nSe även EMAIL_PORT.
EMAIL_HOST_PASSWORDLink to this heading#Standard: '' (tom sträng)
Lösenord som ska användas för SMTP-servern som definieras i EMAIL_HOST. Denna inställning används tillsammans med EMAIL_HOST_USER vid autentisering mot SMTP-servern. Om någon av dessa inställningar är tom kommer Django inte att försöka autentisera.
Se även EMAIL_HOST_USER.
EMAIL_HOST_USERLink to this heading#Standard: '' (tom sträng)
Användarnamn att använda för SMTP-servern som definieras i EMAIL_HOST. Om det är tomt kommer Django inte att försöka autentisera.
Se även EMAIL_HOST_PASSWORD.
EMAIL_PORTLink to this heading#Standard: 25
Port som ska användas för den SMTP-server som definieras i EMAIL_HOST.
EMAIL_SUBJECT_PREFIXLink to this heading#Standard: '[Django] '
Prefix för ämnesraden i e-postmeddelanden som skickas med django.core.mail.mail_admins eller django.core.mail.mail_managers. Du kommer förmodligen att vilja inkludera det efterföljande mellanslaget.
EMAIL_ANVÄNDNING_LOKALTIDLink to this heading#Standard: False
Om SMTP-rubriken Date för e-postmeddelanden ska skickas i den lokala tidszonen (True) eller i UTC (False).
EMAIL_USE_TLSLink to this heading#Standard: False
Om du vill använda en TLS-anslutning (säker) när du pratar med SMTP-servern. Detta används för explicita TLS-anslutningar, i allmänhet på port 587. Om du upplever att anslutningarna hänger sig, se den implicita TLS-inställningen EMAIL_USE_SSL.
EMAIL_USE_SSLLink to this heading#Standard: False
Om du vill använda en implicit TLS-anslutning (säker) när du pratar med SMTP-servern. I de flesta e-postdokumentationer kallas den här typen av TLS-anslutning för SSL. Den används i allmänhet på port 465. Om du upplever problem, se den explicita TLS-inställningen EMAIL_USE_TLS.
Observera att EMAIL_USE_TLS/EMAIL_USE_SSL är ömsesidigt uteslutande, så sätt bara en av dessa inställningar till True.
EMAIL_SSL_CERTFILELink to this heading#Standard: None
Om EMAIL_USE_SSL eller EMAIL_USE_TLS är True och den säkra anslutningen till SMTP-servern kräver klientautentisering, ska du använda den här inställningen för att ange sökvägen till en PEM-formaterad certifikatkedjefil, som måste användas tillsammans med EMAIL_SSL_KEYFILE.
EMAIL_SSL_CERTFILE bör inte användas med ett självsignerat servercertifikat eller ett certifikat från en privat certifikatutfärdare (CA). I sådana fall bör serverns certifikat (eller rotcertifikatet för den privata certifikatutfärdaren) installeras i systemets CA-paket. Detta kan göras genom att följa plattformsspecifika instruktioner för installation av ett rotcertifikat från en certifikatutfärdare, eller genom att använda OpenSSL:s miljövariabler SSL_CERT_FILE eller SSL_CERT_DIR för att ange en anpassad certifikatbunt (om det inte är möjligt eller önskvärt att ändra systembunten).
För mer komplexa scenarier kan SMTP EmailBackend subklassas för att lägga till rotcertifikat till dess ssl_context med ssl.SSLContext.load_verify_locations().
EMAIL_SSL_KEYFILELink to this heading#Standard: None
Om EMAIL_USE_SSL eller EMAIL_USE_TLS är True kan du eventuellt ange sökvägen till en PEM-formaterad privat nyckelfil för klientautentisering av SSL-anslutningen tillsammans med EMAIL_SSL_CERTFILE.
Observera att inställningarna EMAIL_SSL_CERTFILE och EMAIL_SSL_KEYFILE inte leder till någon kontroll av certifikat. De skickas till den underliggande SSL-anslutningen. Se dokumentationen för Pythons funktion ssl.SSLContext.wrap_socket() för detaljer om hur certifikatkedjefilen och den privata nyckelfilen hanteras.
EMAIL_TIMEOUTLink to this heading#Standard: None
Anger en timeout i sekunder för blockering av åtgärder som anslutningsförsök.
\nFIL_UPPLADDNING_HANTERARELink to this heading#Standard:
\n[\n "django.core.files.uploadhandler.MemoryFileUploadHandler",\n "django.core.files.uploadhandler.TemporaryFileUploadHandler",\n]\nEn lista över hanterare som ska användas för uppladdning. Om du ändrar den här inställningen kan du helt anpassa - till och med ersätta - Djangos uppladdningsprocess.
\nSe Hantera filer för mer information.
\nFILE_UPLOAD_MAX_MEMORY_SIZELink to this heading#Standard: 2621440 (dvs. 2,5 MB).
Den maximala storleken (i byte) som en uppladdning kommer att ha innan den strömmas till filsystemet. Se Hantera filer för mer information.
\nSe även DATA_UPLOAD_MAX_MEMORY_SIZE.
FILE_UPLOAD_DIRECTORY_PERMISSIONSLink to this heading#Standard: None
Det numeriska läge som ska tillämpas på kataloger som skapas i samband med att filer laddas upp.
\nDen här inställningen bestämmer också standardbehörigheterna för insamlade statiska kataloger när kommandot collectstatic används. Se collectstatic för information om hur du åsidosätter den.
Detta värde speglar funktionaliteten och förbehållen i inställningen FILE_UPLOAD_PERMISSIONS.
FILE_UPLOAD_PERMISSIONSLink to this heading#Standard: 0o644
Det numeriska läget (t.ex. 0o644) som nyuppladdade filer ska ställas in på. För mer information om vad dessa lägen betyder, se dokumentationen för os.chmod().
Om None får du ett beteende som är beroende av operativsystemet. På de flesta plattformar har temporära filer läget 0o600 och filer som sparas från minnet sparas med hjälp av systemets standard-umask.
Av säkerhetsskäl tillämpas inte dessa behörigheter på de temporära filer som lagras i FILE_UPLOAD_TEMP_DIR.
Den här inställningen bestämmer också standardbehörigheterna för insamlade statiska filer när kommandot collectstatic används. Se collectstatic för information om hur du åsidosätter den.
FILE_UPLOAD_TEMP_DIRLink to this heading#Standard: None
Den katalog som data ska lagras i (vanligtvis filer som är större än FILE_UPLOAD_MAX_MEMORY_SIZE) tillfälligt under uppladdning av filer. Om None, kommer Django att använda den temporära standardkatalogen för operativsystemet. Till exempel: kommer detta som standard att vara /tmp på *nix-liknande operativsystem.
Se Hantera filer för mer information.
\nFÖRSTA_DAGEN_I_VECKANLink to this heading#Standard: 0 (söndag)
Ett tal som representerar den första dagen i veckan. Detta är särskilt användbart när du visar en kalender. Detta värde används endast när internationalisering av format inte används, eller när ett format inte kan hittas för den aktuella lokalen.
\nVärdet måste vara ett heltal från 0 till 6, där 0 betyder söndag, 1 betyder måndag och så vidare.
\nFIXTURE_DIRSLink to this heading#Standard: [] (tom lista)
Lista över kataloger som genomsökts efter fixture-filer, utöver katalogen fixtures för varje program, i sökordning.
Observera att dessa sökvägar ska använda snedstreck i Unix-stil, även under Windows.
\n\nFORCERA_SKRIPTNAMNLink to this heading#Standard: None
Om inte None, kommer detta att användas som värde för miljövariabeln SCRIPT_NAME i alla HTTP-begäranden. Denna inställning kan användas för att åsidosätta det serverlevererade värdet för SCRIPT_NAME, som kan vara en omskriven version av det föredragna värdet eller inte levereras alls. Den används också av django.setup() för att ställa in URL-resolverns skriptprefix utanför begäran/svar-cykeln (t.ex. i hanteringskommandon och fristående skript) för att generera korrekta webbadresser när FORCE_SCRIPT_NAME tillhandahålls.
FORM_RENDERERLink to this heading#Standard: 'django.forms.renderers.DjangoTemplates`’```
Klassen som renderar formulär och formulärwidgets. Den måste implementera lågnivå rendering API. Inkluderade formulärrenderingar är:
\n'django.forms.renderers.DjangoTemplates`’``
'django.forms.renderers.Jinja2` '
'django.forms.renderers.TemplatesSetting` '
FORMULÄR_URLFIELD_ASSUME_HTTPSLink to this heading#Standard: False
Ställ in denna övergångsinställning till True för att välja att använda "https" som det nya standardvärdet för URLField.assume_scheme under Django 5.x release cycle.
FORMAT_MODUL_ SÖKVÄGLink to this heading#Standard: None
En fullständig Python-sökväg till ett Python-paket som innehåller anpassade formatdefinitioner för projektets lokala. Om inte None, kommer Django att söka efter en formats.py-fil, under katalogen som heter som den aktuella lokalen, och kommer att använda de format som definieras i den här filen.
Namnet på den katalog som innehåller formatdefinitionerna förväntas vara namngivet med locale name-notation, t.ex. de, pt_BR, en_US, etc.
Till exempel:, om FORMAT_MODULE_PATH är inställd på mysite.formats, och det aktuella språket är en (engelska), kommer Django att förvänta sig ett katalogträd som:
mysite/\n formats/\n __init__.py\n en/\n __init__.py\n formats.py\nDu kan också ange en lista med Python-sökvägar, t.ex.:
\nFORMAT_MODULE_PATH = [\n "mysite.formats",\n "some_app.formats",\n]\nNär Django söker efter ett visst format kommer den att gå igenom alla givna Python-sökvägar tills den hittar en modul som faktiskt definierar det givna formatet. Detta innebär att format som definieras i paket längre upp i listan kommer att ha företräde framför samma format i paket längre ner.
\nTillgängliga format är:
\n\nStandard: [] (tom lista)
Lista över kompilerade objekt med reguljära uttryck som beskriver webbadresser som bör ignoreras vid rapportering av HTTP 404-fel via e-post (se Hur man hanterar felrapportering). Reguljära uttryck matchas mot requests fullständiga sökvägar (inklusive frågesträng, om någon). Använd detta om din webbplats inte tillhandahåller en vanligt begärd fil som favicon.ico eller robots.txt.
Detta används endast om BrokenLinkEmailsMiddleware är aktiverat (se Middleware).
INSTALLERADE_APPARLink to this heading#Standard: [] (tom lista)
En lista med strängar som anger alla applikationer som är aktiverade i den här Django-installationen. Varje sträng ska vara en prickad Python-sökväg till:
\nen applikationskonfigurationsklass (föredras), eller
ett paket som innehåller en ansökan.
Lär dig mer om applikationskonfigurationer.
\n\n\nNär flera program tillhandahåller olika versioner av samma resurs (mall, statisk fil, hanteringskommando, översättning) har det program som anges först i INSTALLED_APPS företräde.
INTERNA_IPSLink to this heading#Standard: [] (tom lista)
En lista med IP-adresser, som strängar, som:
\nTillåt kontextprocessorn debug() att lägga till några variabler i mallkontexten.
Kan använda admindocs bookmarklets även om du inte är inloggad som personalanvändare.
Markeras som ”intern” (i motsats till ”EXTERN”) i AdminEmailHandler e-postmeddelanden.
SPRÅK_KODLink to this heading#Standard: 'en-us'
En sträng som representerar språkkoden för den här installationen. Detta bör vara i standard språk-ID-format. Till exempel: är U.S. English "en-us". Se även lista över språkidentifierare och Internationalisering och lokalisering.
Den tjänar tre syften:
\nOm locale middleware inte används bestämmer den vilken översättning som ska visas för alla användare.
Om locale middleware är aktivt tillhandahåller det ett reservspråk om användarens önskade språk inte kan bestämmas eller inte stöds av webbplatsen. Det ger också en reservöversättning när en översättning för en viss bokstav inte finns för användarens föredragna språk.
Om lokalisering uttryckligen är inaktiverad via filtret unlocalize eller taggen {% localize off %}, tillhandahåller den reservformat för lokalisering som kommer att användas istället. Se kontrollera lokalisering i mallar för detaljer.
Se Hur Django upptäcker språkpreferenser för mer information.
\nLANGUAGESLink to this heading#Standardinställning: En lista över alla tillgängliga språk. Denna lista växer kontinuerligt och att inkludera en kopia här skulle oundvikligen bli snabbt inaktuellt. Du kan se den aktuella listan över översatta språk genom att titta i django/conf/global_settings.py.
\nListan är en lista med 2-tuples i formatet (språkkod, språknamn) – till exempel ('ja', 'japanska'). Detta anger vilka språk som är tillgängliga för språkval. Se Internationalisering och lokalisering.
I allmänhet bör standardvärdet vara tillräckligt. Ange endast den här inställningen om du vill begränsa språkvalet till en delmängd av de språk som Django tillhandahåller.
\nOm du definierar en anpassad LANGUAGES-inställning kan du markera språknamnen som översättningssträngar med gettext_lazy()-funktionen.
Här är ett exempel på en inställningsfil:
\nfrom django.utils.translation import gettext_lazy as _\n\nLANGUAGES = [\n ("de", _("German")),\n ("en", _("English")),\n]\nSPRÅK_BIDILink to this heading#Standard: En lista med alla språkkoder som skrivs från höger till vänster. Du kan se den aktuella listan över dessa språk genom att titta i django/conf/global_settings.py.
\nListan innehåller språkkoder för språk som skrivs från höger till vänster.
\nI allmänhet bör standardvärdet vara tillräckligt. Ange endast den här inställningen om du vill begränsa språkvalet till en delmängd av de språk som Django tillhandahåller. Om du definierar en anpassad LANGUAGES-inställning kan listan över dubbelriktade språk innehålla språkkoder som inte är aktiverade på en viss webbplats.
LOKALA SÖKVÄGARLink to this heading#Standard: [] (tom lista)
En lista över kataloger där Django letar efter översättningsfiler. Se hur-django-discovers-translations.
\nExempel:
\nLOCALE_PATHS = [\n "/home/www/project/common_files/locale",\n "/var/local/translations/locale",\n]\nDjango kommer att leta inom var och en av dessa sökvägar efter katalogerna <locale_code>/LC_MESSAGES som innehåller de faktiska översättningsfilerna.
LOGGINGLink to this heading#Standard: En ordbok för loggningskonfiguration.
\nEn datastruktur som innehåller konfigurationsinformation. Om den inte är tom kommer innehållet i denna datastruktur att skickas som argument till den konfigurationsmetod som beskrivs i LOGGING_CONFIG.
Standardkonfigurationen för loggning skickar bland annat HTTP 500-serverfel till en e-postlogghanterare när DEBUG är False. Se även Konfigurera loggning.
Du kan se standardkonfigurationen för loggning genom att titta i django/utils/log.py.
\nLOGGING_CONFIGLink to this heading#Standard: 'logging.config.dictConfig'
En sökväg till en callable som kommer att användas för att konfigurera loggning i Django-projektet. Pekar på en instans av Pythons dictConfig konfigurationsmetod som standard.
\nOm du anger LOGGING_CONFIG till None, hoppar du över konfigurationen av loggningsprocessen.
FÖRVALTARELink to this heading#Standard: [] (tom lista)
En lista i samma format som ADMINS som anger vem som ska få meddelanden om brutna länkar när BrokenLinkEmailsMiddleware är aktiverat.
MEDIA_ROOTLink to this heading#Standard: '' (tom sträng)
Absolut filsystemssökväg till den katalog som ska innehålla user-uploaded files.
\nExempel: "/var/www/example.com/media/"
Se även MEDIA_URL.
MEDIA_URLLink to this heading#Standard: '' (tom sträng)
URL som hanterar media som serveras från MEDIA_ROOT, används för hantering av lagrade filer. Den måste sluta med ett snedstreck om den är satt till ett icke-tomt värde. Du måste konfigurera dessa filer så att de serveras i både utvecklings- och produktionsmiljöer.
Om du vill använda {{ MEDIA_URL }} i dina mallar, lägg till 'django.template.context_processors.media' i alternativet 'context_processors' i TEMPLATES.
Exempel: "https://media.example.com/"
MIDDLEWARELink to this heading#Standard: None
En lista över mellanprogram som ska användas. Se Middleware.
\nMIGRATION_MODULESLink to this heading#Standard: {} (Tom ordbok)
En ordbok som anger det paket där migreringsmoduler kan hittas per app. Standardvärdet för den här inställningen är en tom ordbok, men standardpaketnamnet för migreringsmoduler är migrations.
Exempel:
\n{"blog": "blog.db_migrations"}\nI det här fallet kommer migreringar som rör appen blog att finnas i paketet blog.db_migrations.
Om du anger argumentet app_label kommer makemigrations automatiskt att skapa paketet om det inte redan finns.
När du anger None som ett värde för en app kommer Django att betrakta appen som en app utan migreringar oavsett om det finns en befintlig migrations-undermodul. Detta kan till exempel användas i en testinställningsfil för att hoppa över migreringar under testning (tabeller kommer fortfarande att skapas för apparnas modeller). Om du vill inaktivera migreringar för alla appar under tester kan du i stället ställa in MIGRATE till False. Om MIGRATION_MODULES används i dina allmänna projektinställningar, kom ihåg att använda alternativet migrate --run-syncdb om du vill skapa tabeller för appen.
MÅNAD_DAG_FORMATLink to this heading#Standard: 'F j'
Standardformateringen som ska användas för datumfält på Django-administratörens ändringslistsidor - och eventuellt av andra delar av systemet - i de fall då endast månad och dag visas.
\nTill exempel:, när en Django-administratörs sida med ändringslistor filtreras med en datumdrilldown, visar rubriken för en viss dag dag och månad. Olika lokala språk har olika format. Till exempel: skulle amerikansk engelska säga ”1 januari”, medan spanska kan säga ”1 Enero”
\nObservera att motsvarande lokalt dikterat format har högre prioritet och kommer att tillämpas istället.
\nSe tillåtna datumformatsträngar. Se även DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT och YEAR_MONTH_FORMAT.
NUMMER_GRUPPERINGLink to this heading#Standard: 0
Antal siffror som är grupperade tillsammans i heltalsdelen av ett tal.
\nVanlig användning är att visa en tusenskillnad. Om denna inställning är 0, kommer ingen gruppering att tillämpas på talet. Om den här inställningen är större än 0, kommer THOUSAND_SEPARATOR` att användas som separator mellan dessa grupper.
Vissa lokala enheter använder icke-uniform siffergruppering, t.ex. 10,00,00,000 i en_IN. I sådana fall kan du ange en sekvens med det antal siffergruppstorlekar som ska tillämpas. Det första talet definierar storleken på den grupp som föregår decimalavgränsaren, och varje tal som följer definierar storleken på de föregående grupperna. Om sekvensen avslutas med -1 utförs ingen ytterligare gruppering. Om sekvensen avslutas med 0 används den sista gruppstorleken för återstoden av numret.
Exempel på tupel för en_IN:
NUMBER_GROUPING = (3, 2, 0)\nObservera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas i stället.
\nSe även DECIMAL_SEPARATOR, THOUSAND_SEPARATOR och USE_THOUSAND_SEPARATOR.
PREPEND_WWWLink to this heading#Standard: False
Om ”www.”-underdomänen ska läggas till i URL:er som inte har det. Detta används endast om CommonMiddleware är installerat (se Middleware). Se även APPEND_SLASH.
ROOT_URLCONFLink to this heading#Standard: Ej definierad
\nEn sträng som representerar den fullständiga Python-importvägen till din rot-URLconf, till exempel "mydjangoapps.urls". Kan åsidosättas per begäran genom att ställa in attributet urlconf på det inkommande HttpRequest-objektet. Se Hur Django behandlar en förfrågan för detaljer.
SECRET_KEYLink to this heading#Standard: '' (tom sträng)
En hemlig nyckel för en viss Django-installation. Den används för att tillhandahålla kryptografisk signering, och bör sättas till ett unikt, oförutsägbart värde.
\ndjango-admin startproject lägger automatiskt till en slumpmässigt genererad SECRET_KEY till varje nytt projekt.
Användningar av nyckeln bör inte förutsätta att det är text eller bytes. Varje användning bör gå igenom force_str() eller force_bytes() för att konvertera den till önskad typ.
Django kommer att vägra att starta om SECRET_KEY inte är inställd.
Den hemliga nyckeln används för:
\nAlla sessions om du använder någon annan session backend än django.contrib.sessions.backends.cache, eller använder standard get_session_auth_hash().
Alla messages om du använder CookieStorage eller FallbackStorage.
Alla PasswordResetView tokens.
All användning av kryptografisk signering, såvida inte en annan nyckel anges.
När en hemlig nyckel inte längre är inställd som SECRET_KEY eller finns i SECRET_KEY_FALLBACKS kommer allt ovan att ogiltigförklaras. När du byter ut din hemliga nyckel bör du flytta den gamla nyckeln till SECRET_KEY_FALLBACKS tillfälligt. Hemliga nycklar används inte för användares lösenord och nyckelrotation påverkar inte dem.
SEKRETESS_NYCKEL_FALLBACKLink to this heading#Standard: []
En lista över hemliga reservnycklar för en viss Django-installation. Dessa används för att tillåta rotation av SECRET_KEY.
För att rotera dina hemliga nycklar anger du en ny SECRET_KEY och flyttar det tidigare värdet till början av SECRET_KEY_FALLBACKS. Ta sedan bort de gamla värdena från slutet av SECRET_KEY_FALLBACKS när du är redo att avsluta sessionerna, tokens för återställning av lösenord och så vidare som använder dem.
Användningar av de hemliga nyckelvärdena bör inte förutsätta att de är text eller byte. Varje användning bör gå igenom force_str() eller force_bytes() för att konvertera den till önskad typ.
SECURE_CONTENT_TYPE_NOSNIFFLink to this heading#Standard: True
Om True, ställer SecurityMiddleware in X-Content-Type-Options: nosniff-huvudet på alla svar som inte redan har det.
Standard: 'same-origin'
Om den inte är inställd på None, ställer SecurityMiddleware in Policy för öppnare för flera ursprung-huvudet på alla svar som inte redan har det till det angivna värdet.
SECURE_HSTS_INCLUDE_SUBDOMAINSLink to this heading#Standard: False
Om True, lägger SecurityMiddleware till direktivet includeSubDomains till HTTP Strict Transport Security-huvudet. Det har ingen effekt om inte SECURE_HSTS_SECONDS är satt till ett värde som inte är noll.
SÄKER_HSTS_FÖRLADDNINGLink to this heading#Standard: False
Om True, lägger SecurityMiddleware till preload-direktivet till HTTP Strict Transport Security-huvudet. Det har ingen effekt om inte SECURE_HSTS_SECONDS är satt till ett värde som inte är noll.
SECURE_HSTS_SEKUNDERLink to this heading#Standard: 0
Om det anges till ett heltal som inte är noll anger SecurityMiddleware HTTP Strict Transport Security-huvudet på alla svar som inte redan har det.
SECURE_PROXY_SSL_HEADERLink to this heading#Standard: None
En tupel som representerar en kombination av HTTP-rubrik/värde som visar att en begäran är säker. Detta styr beteendet hos request-objektets metod is_secure().
Som standard avgör is_secure() om en förfrågan är säker genom att bekräfta att en begärd URL använder https://. Denna metod är viktig för Djangos CSRF-skydd och den kan användas av din egen kod eller appar från tredje part.
Om din Django-app är bakom en proxy kan proxyn dock ”svälja” oavsett om den ursprungliga begäran använder HTTPS eller inte. Om det finns en icke-HTTPS-anslutning mellan proxyn och Django skulle is_secure() alltid returnera False - även för förfrågningar som gjordes via HTTPS av slutanvändaren. Om det däremot finns en HTTPS-anslutning mellan proxyn och Django kommer is_secure() alltid att returnera True - även för förfrågningar som ursprungligen gjordes via HTTP.
I den här situationen ska du konfigurera din proxy så att den anger en anpassad HTTP-header som talar om för Django om begäran kom in via HTTPS, och ange SECURE_PROXY_SSL_HEADER så att Django vet vilken header de ska leta efter.
Ställ in en tuple med två element - namnet på den header som ska sökas och det värde som krävs. Till exempel:
\nSECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")\nDetta säger till Django att lita på rubriken X-Forwarded-Proto som kommer från vår proxy och att begäran garanterat är säker (dvs. den kom ursprungligen in via HTTPS) när:
rubrikvärdet är 'https', eller
dess första värde längst till vänster är 'https' när det gäller en kommaseparerad lista över protokoll (t.ex. 'https,http,http').
Du bör endast ange denna inställning om du kontrollerar din proxy eller har någon annan garanti för att den anger/avlägsnar denna rubrik på lämpligt sätt.
\nObservera att rubriken måste vara i det format som används av request.META - alla versaler och sannolikt börja med HTTP_. (Kom ihåg att Django automatiskt lägger till 'HTTP_' i början av x-header-namn innan rubriken görs tillgänglig i request.META)
SÄKER_OMDIRIGERING_BEFRIADLink to this heading#Standard: [] (tom lista)
Om en URL-sökväg matchar ett reguljärt uttryck i den här listan kommer begäran inte att omdirigeras till HTTPS. SecurityMiddleware tar bort ledande snedstreck från URL-sökvägar, så mönster bör inte innehålla dem, t.ex. SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', ...]. Om SECURE_SSL_REDIRECT är False har denna inställning ingen effekt.
POLICY FÖR SÄKRA REFERENSER SECURE_REFERRER_POLICYLink to this heading#Standard: 'same-origin'
Om den konfigureras ställer SecurityMiddleware in Policy för hänvisare-huvudet på alla svar som inte redan har det till det angivna värdet.
SECURE_SSL_HOSTLink to this heading#Standard: None
Om det är en sträng (t.ex. secure.example.com) kommer alla SSL-omdirigeringar att skickas till den här värden i stället för den ursprungligen begärda värden (t.ex. www.example.com). Om SECURE_SSL_REDIRECT är False har denna inställning ingen effekt.
SÄKER_SSL_OMDIRIGERINGLink to this heading#Standard: False
Om True, SecurityMiddleware redirects alla icke-HTTPS-förfrågningar till HTTPS (utom för de URL:er som matchar ett reguljärt uttryck som anges i SECURE_REDIRECT_EXEMPT).
SERIALIZATION_MODULESLink to this heading#Standard: Ej definierad
\nEn ordbok med moduler som innehåller serialiseringsdefinitioner (i form av strängar), med en nyckel i form av en strängidentifierare för serialiseringstypen. Om du t.ex. vill definiera en YAML-serialisator använder du:
\nSERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}\nSERVER_EMAILLink to this heading#Standard: 'root@localhost'
E-postadressen som felmeddelanden kommer från, t.ex. de som skickas till ADMINS och MANAGERS. Den här adressen används i rubriken From: och kan ha vilket format som helst som är giltigt i det valda e-postprotokollet.
KORT_DATUM_FORMATLink to this heading#Standard: 'm/d/Y (t.ex. 12/31/2003)
En tillgänglig formatering som kan användas för att visa datumfält på mallar. Observera att motsvarande lokalt dikterat format har högre prioritet och kommer att tillämpas istället. Se tillåtna datumformatsträngar.
Se även DATE_FORMAT och SHORT_DATETIME_FORMAT.
KORT_DATATID_FORMATLink to this heading#Standard: 'm/d/Y P' (t.ex. 12/31/2003 4 p.m.)
En tillgänglig formatering som kan användas för att visa datetime-fält på mallar. Observera att motsvarande lokalt dikterade format har högre prioritet och kommer att tillämpas istället. Se tillåtna datumformatsträngar.
Se även DATE_FORMAT och SHORT_DATE_FORMAT.
SIGNING_BACKENDLink to this heading#Standard: 'django.core.signing.TimestampSigner'
Den backend som används för att signera cookies och andra data.
\nSe även dokumentationen Kryptografisk signering.
\nFÖRSVAGADE_SYSTEMKONTROLLERLink to this heading#Standard: [] (tom lista)
En lista med identifierare för meddelanden som genereras av ramverket för systemkontroller (t.ex. ["models.W001"]) som du vill bekräfta och ignorera permanent. Tystade kontroller kommer inte att matas ut till konsolen.
Se även dokumentationen Ramverk för systemkontroll.
\nFÖRVARINGARLink to this heading#Standard:
\n{\n "default": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n },\n "staticfiles": {\n "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",\n },\n}\nEn ordbok som innehåller inställningarna för alla lagringsutrymmen som ska användas med Django. Det är en nästlad ordbok vars innehåll mappar ett lagringsalias till en ordbok som innehåller alternativen för en enskild lagring.
\nFörråd kan ha vilket alias du vill. Det finns dock två alias som har särskild betydelse:
\ndefault för hantering av filer. 'django.core.files.storage.FileSystemStorage' är standardlagringsmotorn.
staticfiles för hantera statiska filer. 'django.contrib.staticfiles.storage.StaticFilesStorage` ' är standardlagringsmotorn.
Följande är ett exempel på ett utdrag ur settings.py som definierar en anpassad fillagring som heter example:
STORAGES = {\n # ...\n "example": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n "OPTIONS": {\n "location": "/example",\n "base_url": "/example/",\n },\n },\n}\nOPTIONS skickas till BACKEND vid initiering i **kwargs.
En färdiginstallerad instans av lagringsbackends kan hämtas från django.core.files.storage.storages. Använd en nyckel som motsvarar backend-definitionen i STORAGES.
TEMPLATESLink to this heading#Standard: [] (tom lista)
En lista som innehåller inställningarna för alla mallmotorer som ska användas med Django. Varje objekt i listan är en ordbok som innehåller alternativen för en enskild motor.
\nHär är en inställning som säger till Djangos mallmotor att ladda mallar från underkatalogen templates i varje installerat program:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "APP_DIRS": True,\n },\n]\nFöljande alternativ är tillgängliga för alla backends.
\nBACKENDLink to this heading#Standard: Ej definierad
\nDen mallbackend som ska användas. De inbyggda mallbackendsen är:
\n'django.template.backends.django.DjangoTemplates'
'django.template.backends.jinja2.Jinja2'
Du kan använda en mallbackend som inte levereras med Django genom att ställa in BACKEND till en fullständigt kvalificerad sökväg (dvs. 'mypackage.whatever.Backend').
NAMELink to this heading#Standard: se nedan
\nAliaset för just den här mallmotorn. Det är en identifierare som gör det möjligt att välja en motor för rendering. Alias måste vara unika för alla konfigurerade mallmotorer.
\nDet är standardnamnet på modulen som definierar motorklassen, dvs. den näst sista delen av BACKEND, om det inte anges. Till exempel: om backend är 'mypackage.whatever.Backend' så är dess standardnamn 'whatever'.
DIRSLink to this heading#Standard: [] (tom lista)
Kataloger där sökmotorn ska leta efter mallens källfiler, i sökordning.
\nAPP_DIRSLink to this heading#Standard: False
Om sökmotorn ska leta efter mallkällfiler i installerade program.
\n\nOPTIONSLink to this heading#Standard: {} (Tom dikt)
Extra parametrar att skicka till mallens backend. Tillgängliga parametrar varierar beroende på mallens backend. Se DjangoTemplates och Jinja2 för alternativen för de inbyggda backends.
TEST_RUNNERLink to this heading#Standard: 'django.test.runner.DiscoverRunner'
Namnet på den klass som ska användas för att starta testsviten. Se andra ramverk för testning.
\nTEST_NON_SERIALIZED_APPSLink to this heading#Standard: [] (tom lista)
För att återställa databastillståndet mellan tester för TransactionTestCase och databasbackends utan transaktioner, kommer Django att serialisera innehållet i alla appar när den startar testkörningen så att den sedan kan ladda om från den kopian innan den kör tester som behöver det.
Detta saktar ner starttiden för testköraren; om du har appar som du vet inte behöver den här funktionen kan du lägga till deras fullständiga namn här (t.ex. 'django.contrib.contenttypes') för att utesluta dem från denna serialiseringsprocess.
TUSENTALS_SEPARATORLink to this heading#Standard: ',' (Komma)
Standardavgränsare för tusen som används vid formatering av tal. Denna inställning används endast när USE_THOUSAND_SEPARATOR är True och NUMBER_GROUPING är större än 0.
Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas i stället.
\nSe även NUMBER_GROUPING, DECIMAL_SEPARATOR och USE_THOUSAND_SEPARATOR.
TID_FORMATLink to this heading#Standard: 'P' (t.ex. 4 p.m.)
Standardformateringen som ska användas för att visa tidsfält i alla delar av systemet. Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället. Se tillåtna datumformatsträngar.
Se även DATE_FORMAT och DATETIME_FORMAT.
TID_INMATNINGSFORMATLink to this heading#Standard:
\n[\n "%H:%M:%S", # '14:30:59'\n "%H:%M:%S.%f", # '14:30:59.000200'\n "%H:%M", # '14:30'\n]\nEn lista över format som accepteras vid inmatning av data i ett tidsfält. Formaten prövas i ordning och det första giltiga formatet används. Observera att dessa formatsträngar använder Pythons datetime-modulsyntax, inte formatsträngarna från date-mallfiltret.
Det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället.
\nSe även DATE_INPUT_FORMATS och DATETIME_INPUT_FORMATS.
TIME_ZONELink to this heading#Standard: 'Amerika/Chicago'
En sträng som representerar tidszonen för den här installationen. Se lista över tidszoner.
\n\nObservera att detta inte nödvändigtvis är serverns tidszon. Till exempel: kan en server betjäna flera Django-drivna webbplatser, var och en med en separat tidszonsinställning.
\nNär USE_TZ är False, är detta den tidszon som Django kommer att lagra alla datatider i. När USE_TZ är True är detta den standardtidszon som Django kommer att använda för att visa datatider i mallar och för att tolka datatider som skrivs in i formulär.
I Unix-miljöer (där time.tzset() är implementerad) ställer Django in variabeln os.environ['TZ'] till den tidszon som du anger i inställningen TIME_ZONE. På så sätt kommer alla dina vyer och modeller automatiskt att fungera i denna tidszon. Django kommer dock inte att ställa in miljövariabeln TZ om du använder alternativet manuell konfiguration enligt beskrivningen i manuell konfiguration av inställningar. Om Django inte ställer in miljövariabeln TZ är det upp till dig att se till att dina processer körs i rätt miljö.
USE_I18NLink to this heading#Standard: True
En boolean som anger om Djangos översättningssystem ska vara aktiverat. Detta ger ett sätt att stänga av det, för prestanda. Om detta är inställt på False, kommer Django att göra vissa optimeringar för att inte ladda översättningsmaskineriet.
Se även LANGUAGE_CODE och USE_TZ.
ANVÄNDA_TUSENTALS_SEPARATORLink to this heading#Standard: False
En boolean som anger om siffror ska visas med en tusentalsavgränsare. När inställningen är True kommer Django att formatera siffror med hjälp av inställningarna NUMBER_GROUPING och THOUSAND_SEPARATOR. De två sistnämnda inställningarna kan också dikteras av lokalen, som har företräde.
Se även DECIMAL_SEPARATOR, NUMBER_GROUPING och THOUSAND_SEPARATOR.
USE_TZLink to this heading#Standard: True
Ett boolean som anger om datatider ska vara tidszonsmedvetna som standard eller inte. Om detta är inställt på True kommer Django att använda tidszonmedvetna datatider internt.
När USE_TZ är False, kommer Django att använda naiva datatider i lokal tid, utom vid parsning av ISO 8601-formaterade strängar, där tidszoninformation alltid kommer att behållas om den finns.
USE_X_FORWARDED_HOSTLink to this heading#Standard: False
Ett boolean som anger om rubriken X-Forwarded-Host ska användas i stället för rubriken Host. Detta bör endast aktiveras om en proxy som ställer in detta huvud används.
Denna inställning har prioritet över USE_X_FORWARDED_PORT. Enligt RFC 7239 Section 5.3 kan rubriken X-Forwarded-Host innehålla portnumret, i vilket fall du inte bör använda USE_X_FORWARDED_PORT.
USE_X_FORWARDED_PORTLink to this heading#Standard: False
Ett boolean-värde som anger om rubriken X-Forwarded-Port ska användas i stället för variabeln META SERVER_PORT. Detta bör endast aktiveras om en proxy som ställer in detta huvud används.
USE_X_FORWARDED_HOST har prioritet över denna inställning.
WSGI_APPLIKATIONLink to this heading#Standard: None
Den fullständiga Python-sökvägen till WSGI-applikationsobjektet som Djangos inbyggda servrar (t.ex. runserver) kommer att använda. Ledningskommandot django-admin startproject kommer att skapa en standardfil wsgi.py med en application callable i den, och peka denna inställning till den application.
Om den inte är inställd kommer returvärdet för django.core.wsgi.get_wsgi_application() att användas. I det här fallet kommer beteendet för runserver att vara identiskt med tidigare Django-versioner.
ÅR_MÅNAD_FORMATLink to this heading#Standard: 'F Y'
Standardformateringen som ska användas för datumfält på Django-administratörens ändringslistsidor - och eventuellt av andra delar av systemet - i de fall då endast år och månad visas.
\nTill exempel:, när en Django-administratörs sida med ändringslistor filtreras med en datumdrilldown, visar rubriken för en viss månad månaden och året. Olika lokala språk har olika format. Till exempel: skulle amerikansk engelska säga ”January 2006”, medan en annan lokal skulle säga ”2006/January”
\nObservera att motsvarande lokalt dikterat format har högre prioritet och kommer att tillämpas istället.
\nSe tillåtna datumformatsträngar. Se även DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT och MONTH_DAY_FORMAT.
X_FRAME_OPTIONSLink to this heading#Standard: 'DENY'
Standardvärdet för X-Frame-Options-huvudet som används av XFrameOptionsMiddleware. Se dokumentationen för clickjacking protection.
Inställningar för django.contrib.auth.
AUTENTICATION_BACKENDSLink to this heading#Standard: ['django.contrib.auth.backends.ModelBackend']
En lista över klasser för autentiseringsbackends (som strängar) som ska användas vid försök att autentisera en användare. Se authentication backends documentation för mer information.
\nAUTH_USER_MODELLink to this heading#Standard: 'auth.User'
Den modell som ska användas för att representera en användare. Se Ersätta en anpassad User-modell.
\n\nLOGIN_REDIRECT_URLLink to this heading#Standard: '/accounts/profile/'
URL:en eller namngivet URL-mönster dit förfrågningar omdirigeras efter inloggning när LoginView inte får någon next GET-parameter.
LOGIN_URLLink to this heading#Standard: '/accounts/login/'
URL:en eller namngivet URL-mönster där förfrågningar omdirigeras för inloggning när man använder login_required() decorator, LoginRequiredMixin, AccessMixin, eller när LoginRequiredMiddleware är installerad.
LOGOUT_REDIRECT_URLLink to this heading#Standard: None
URL:en eller namngivet URL-mönster dit förfrågningar omdirigeras efter utloggning om LogoutView inte har attributet next_page.
Om None, kommer ingen omdirigering att utföras och logout-vyn kommer att återges.
LÖSENORD_ÅTERSTÄLL_TIMEOUTLink to this heading#Standard: 259200 (3 dagar, i sekunder)
Antal sekunder som en länk för återställning av lösenord är giltig.
\nAnvänds av PasswordResetConfirmView.
LÖSENORD_HASHERSLink to this heading#Se Hur Django lagrar lösenord.
\nStandard:
\n[\n "django.contrib.auth.hashers.PBKDF2PasswordHasher",\n "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",\n "django.contrib.auth.hashers.Argon2PasswordHasher",\n "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",\n "django.contrib.auth.hashers.ScryptPasswordHasher",\n]\nAUTH_LÖSENORD_VALIDATORERLink to this heading#Standard: [] (tom lista)
Listan över validerare som används för att kontrollera styrkan i användarens lösenord. Se Validering av lösenord för mer information. Som standard utförs ingen validering och alla lösenord accepteras.
\nInställningar för django.contrib.messages.
MEDDELANDE_NIVÅLink to this heading#Standard: meddelanden.INFO
Anger den lägsta meddelandenivån som registreras av meddelanderamen. Se meddelandenivåer för mer information.
\n\nMEDDELANDE_LAGRINGLink to this heading#Standard: 'django.contrib.messages.storage.fallback.FallbackStorage'
Styr var Django lagrar meddelandedata. Giltiga värden är:
\n'django.contrib.messages.storage.fallback.FallbackStorage'
'django.contrib.messages.storage.session.SessionStorage'
'django.contrib.messages.storage.cookie.CookieStorage'
Se backends för meddelandelagring för mer information.
\nDe backends som använder cookies – CookieStorage och FallbackStorage – använder värdet av SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE och SESSION_COOKIE_HTTPONLY när de ställer in sina cookies.
Inställningar för django.contrib.sessions.
SESSION_CACHE_ALIASLink to this heading#Standard: 'default'
Om du använder cache-baserad sessionslagring, väljer du här vilken cache som ska användas.
\nSESSION_ENGINELink to this heading#Standard: 'django.contrib.sessions.backends.db'
Styr var Django lagrar sessionsdata. Inkluderade motorer är:
\n'django.contrib.sessions.backends.db'
'django.contrib.sessions.backends.file'
'django.contrib.sessions.backends.cache'
'django.contrib.sessions.backends.cached_db'
'django.contrib.sessions.backends.signed_cookies'
Se Konfigurera sessionsmotorn för mer information.
\nSESSION_EXPIRE_AT_BROWSER_CLOSELink to this heading#Standard: False
Om sessionen ska upphöra att gälla när användaren stänger webbläsaren. Se Sessioner som varar hela webbläsaren jämfört med permanenta sessioner.
\nSESSION_FILE_PATHLink to this heading#Standard: None
Om du använder filbaserad sessionslagring anger detta den katalog där Django kommer att lagra sessionsdata. När standardvärdet (None) används, kommer Django att använda den temporära standardkatalogen för systemet.
SESSION_SAVE_EVERY_REQUESTLink to this heading#Standard: False
Om sessionsdata ska sparas vid varje begäran. Om detta är False (standard) sparas sessionsdata endast om de har ändrats, dvs. om något av dess ordboksvärden har tilldelats eller tagits bort. Tomma sessioner skapas inte, även om den här inställningen är aktiv.
SESSION_SERIALIZERLink to this heading#Standard: 'django.contrib.sessions.serializers.JSONSerializer' ``
Fullständig importsökväg för en serializer-klass som ska användas för serialisering av sessionsdata. Inkluderad serializer är:
\n'django.contrib.sessions.serializers.JSONSerializer'
Se Serialisering av session för mer information.
\nInställningar för django.contrib.sites.
SITE_IDLink to this heading#Standard: Ej definierad
\nID, i form av ett heltal, för den aktuella webbplatsen i databastabellen django_site. Detta används för att applikationsdata ska kunna kopplas till specifika webbplatser och en enda databas ska kunna hantera innehåll för flera webbplatser.
Inställningar för django.contrib.staticfiles.
STATISK_ROOTLink to this heading#Standard: None
Den absoluta sökvägen till den katalog där collectstatic ska samla in statiska filer för distribution.
Exempel: "/var/www/example.com/static/"
Om contrib-appen staticfiles är aktiverad (som i standardprojektmallen) kommer kommandot collectstatic att samla in statiska filer till den här katalogen. Se guiden hantering av statiska filer för mer information om användning.
STATIC_URLLink to this heading#Standard: None
URL som ska användas vid hänvisning till statiska filer som finns i STATIC_ROOT.
Exempel: "static/" eller "https://static.example.com/"
Om inte None, kommer detta att användas som basväg för asset definitions (klassen Media) och staticfiles app.
Det måste sluta med ett snedstreck om det anges som ett icke-tomt värde.
\nDu kan behöva konfigurera de här filerna så att de serveras under utveckling och du kommer definitivt att behöva göra det under produktion.
\n\nSTATICFILES_DIRSLink to this heading#Standard: [] (tom lista)
Den här inställningen definierar de ytterligare platser som appen staticfiles ska passera om sökfunktionen FileSystemFinder är aktiverad, t.ex. om du använder hanteringskommandot collectstatic eller findstatic eller använder vyn för servering av statiska filer.
Detta bör ställas in på en lista med strängar som innehåller fullständiga sökvägar till dina ytterligare filkataloger, t.ex.:
\nSTATICFILES_DIRS = [\n "/home/special.polls.com/polls/static",\n "/home/polls.com/polls/static",\n "/opt/webfiles/common",\n]\nObservera att dessa sökvägar bör använda snedstreck i Unix-stil, även i Windows (t.ex. "C:/Users/user/mysite/extra_static_content").
Om du vill hänvisa till filer på en av platserna med ett ytterligare namnområde kan du valfritt ange ett prefix som (prefix, sökväg)-tupler, t.ex.:
STATICFILES_DIRS = [\n # ...\n ("downloads", "/opt/webfiles/stats"),\n]\nOm du till exempel antar att du har STATIC_URL inställd på 'static/', skulle kommandot collectstatic samla in ”stats”-filerna i underkatalogen 'downloads' i STATIC_ROOT.
Detta gör att du kan hänvisa till den lokala filen '/opt/webfiles/stats/polls_20101022.tar.gz' med '/static/downloads/polls_20101022.tar.gz' i dina mallar, t.ex:
<a href="{% static 'downloads/polls_20101022.tar.gz' %}">\nSTATISKA FILER_FINDERSLink to this heading#Standard:
\n[\n "django.contrib.staticfiles.finders.FileSystemFinder",\n "django.contrib.staticfiles.finders.AppDirectoriesFinder",\n]\nListan över Finder-backends som vet hur man hittar statiska filer på olika platser.
\nStandardinställningen hittar filer som lagras i inställningen STATICFILES_DIRS (med hjälp av django.contrib.staticfiles.finders.FileSystemFinder) och i en statisk underkatalog för varje app (med hjälp av django.contrib.staticfiles.finders.AppDirectoriesFinder). Om det finns flera filer med samma namn kommer den första filen som hittas att användas.
En sökare är inaktiverad som standard: django.contrib.staticfiles.finders.DefaultStorageFinder. Om den läggs till i inställningen STATICFILES_FINDERS kommer den att leta efter statiska filer i standardfillagringen som definieras av nyckeln default i inställningen STORAGES`.
Statiska filsökare betraktas för närvarande som ett privat gränssnitt, och detta gränssnitt är därför odokumenterat.
\nDATABASER
i18n/l10n`)Link to this heading#i18n)Link to this heading#l10n)Link to this heading#Säkerhet
\n\nSkydd mot Cross Site Request Forgery
\n\nDatabas: TEST