InställningarLink to this heading#

ABSOLUTE_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 = {
    "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.

ADMINSLink 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.

Each item in the list should be an email address string. Example:

ADMINS = ["john@example.com", '"Ng, Mary" <mary@example.com>']

To safely build an address with a display name from variable content, see Formatting email addresses, which recommends using Address over string formatting, but since this setting requires a list of strings, wrap each Address in str(...).

TILLÅ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.

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.

If the Host header (or X-Forwarded-Host if USE_X_FORWARDED_HOST is enabled) does not match any value in this list, the django.http.HttpRequest.get_host() method will raise 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.

This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.

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.

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

CACHESLink to this heading#

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.

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

CACHE_MIDDLEWARE_ALIASLink to this heading#

Standard: 'default'

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

CACHE_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.

Se Djangos ramverk för cache.

CACHE_MIDDLEWARE_SEKUNDERLink to this heading#

Standard: 600

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

Se Djangos ramverk för cache.

CSRF_COOKIE_AGELink to this heading#

Standard: 31449600 (ungefär 1 år, i sekunder)

Åldern på CSRF-cookies, i sekunder.

Anledningen till att man anger en långlivad utgångstid är att man vill undvika problem om en användare stänger webbläsaren eller lägger till ett bokmärke på en sida och sedan laddar sidan från webbläsarens cache. Utan permanenta cookies skulle formuläret inte kunna skickas in i det här fallet.

Vissa webbläsare (särskilt Internet Explorer) kan förbjuda användningen av permanenta cookies eller kan ha indexen till cookie-burken skadade på disken, vilket gör att CSRF-skyddskontroller (ibland intermittent) misslyckas. Ändra den här inställningen till None för att använda sessionsbaserade CSRF-cookies, som håller cookies i minnet istället för på persistent lagring.

CSRF_COOKIE_DOMAINLink to this heading#

Standard: None

The domain to be used when setting the CSRF cookie. This can be useful for easily allowing cross-subdomain requests to be excluded from the normal cross site request forgery protection. It should be set to a string such as ".example.com" to allow a POST request from a form on one subdomain to be accepted by a view served from another subdomain.

Observera att närvaron av denna inställning inte innebär att Djangos CSRF-skydd är säkert från attacker över subdomäner som standard - se avsnittet CSRF-begränsningar.

CSRF_COOKIE_HTTPONLYLink to this heading#

Standard: False

Om flaggan HttpOnly ska användas för CSRF-cookien. Om denna är inställd på True kommer JavaScript på klientsidan inte att kunna komma åt CSRF-cookien.

Att beteckna CSRF-cookien som HttpOnly ger inget praktiskt skydd eftersom CSRF endast är till för att skydda mot attacker över domängränser. Om en angripare kan läsa cookien via JavaScript är de redan på samma domän så vitt webbläsaren vet, så de kan göra vad de vill ändå. (XSS är ett mycket större hål än CSRF.)

Även om inställningen inte ger några praktiska fördelar krävs den ibland av säkerhetsrevisorer.

Om du aktiverar detta och behöver skicka värdet på CSRF-token med en AJAX-begäran måste ditt JavaScript hämta värdet från en dold CSRF-token-formulärinmatning istället för från cookien.

Se SESSION_COOKIE_HTTPONLY för detaljer om HttpOnly.

CSRF_COOKIE_NAMELink to this heading#

Standard: 'csrftoken'

Namnet på den cookie som ska användas för CSRF-autentiseringstoken. Detta kan vara vad du vill (så länge det skiljer sig från de andra cookienamnen i din applikation). Se Skydd mot Cross Site Request Forgery.

CSRF_COOKIE_PATHLink to this heading#

Standard: '/'

Den sökväg som anges i CSRF-cookien. Denna bör antingen matcha URL-sökvägen i din Django-installation eller vara en överordnad del av den sökvägen.

Detta är användbart om du har flera Django-instanser som körs under samma värdnamn. De kan använda olika cookie-sökvägar, och varje instans kommer bara att se sin egen CSRF-cookie.

CSRF_COOKIE_SAMESITELink to this heading#

Standard: 'Lax'

Värdet på flaggan SameSite i CSRF-cookien. Denna flagga förhindrar att cookien skickas i cross-site-begäranden.

Se SESSION_COOKIE_SAMESITE för detaljer om SameSite.

CSRF_COOKIE_SECURELink to this heading#

Standard: False

Om en säker cookie ska användas för CSRF-cookien. Om detta är inställt på True kommer cookien att markeras som ”säker”, vilket innebär att webbläsare kan säkerställa att cookien endast skickas med en HTTPS-anslutning.

CSRF_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.

Eftersom 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:

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_NAMELink to this heading#

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_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.

For a secure (determined by is_secure()) unsafe request that doesn’t include the Origin header, the request must include a Referer header that matches the origin in the Host header.

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.

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:

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

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

DATA_UPLOAD_MAX_MEMORY_SIZELink to this heading#

Standard: 2621440 (dvs. 2,5 MB).

The maximum size in bytes that a request body may be before a SuspiciousOperation (RequestDataTooBig) is raised. The check is done when accessing request.body or request.POST and is calculated against the total request size excluding any file upload data (request.FILES). You can set this to None to disable the check. Applications that are expected to receive unusually large form posts should tune this setting.

Under ASGI, the entire request may be spooled to disk before this limit is enforced. Therefore, it is strongly recommended to place additional protections in front of Django which limit the entire request payload.

The amount of request data is correlated to the amount of memory or storage needed to process the request and populate the GET and POST dictionaries. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don’t typically perform deep request inspection, it’s not possible to perform a similar check at that level.

Se ä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.

DATA_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.

DATABAS_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.

Se dokumentationen om automatisk databasrouting i konfigurationer med flera databaser.

DATUM_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:

[
    "%Y-%m-%d",  # '2006-10-25'
    "%m/%d/%Y",  # '10/25/2006'
    "%m/%d/%y",  # '10/25/06'
    "%b %d %Y",  # 'Oct 25 2006'
    "%b %d, %Y",  # 'Oct 25, 2006'
    "%d %b %Y",  # '25 Oct 2006'
    "%d %b, %Y",  # '25 Oct, 2006'
    "%B %d %Y",  # 'October 25 2006'
    "%B %d, %Y",  # 'October 25, 2006'
    "%d %B %Y",  # '25 October 2006'
    "%d %B, %Y",  # '25 October, 2006'
]

En 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.

Se ä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:

[
    "%Y-%m-%d %H:%M:%S",  # '2006-10-25 14:30:59'
    "%Y-%m-%d %H:%M:%S.%f",  # '2006-10-25 14:30:59.000200'
    "%Y-%m-%d %H:%M",  # '2006-10-25 14:30'
    "%m/%d/%Y %H:%M:%S",  # '10/25/2006 14:30:59'
    "%m/%d/%Y %H:%M:%S.%f",  # '10/25/2006 14:30:59.000200'
    "%m/%d/%Y %H:%M",  # '10/25/2006 14:30'
    "%m/%d/%y %H:%M:%S",  # '10/25/06 14:30:59'
    "%m/%d/%y %H:%M:%S.%f",  # '10/25/06 14:30:59.000200'
    "%m/%d/%y %H:%M",  # '10/25/06 14:30'
]

En 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.

Se även DATE_INPUT_FORMATS och TIME_INPUT_FORMATS.

DEBUGLink to this heading#

Standard: False

Ett boolean som aktiverar/avaktiverar felsökningsläget.

Driftsä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.

Det ä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.

DECIMAL_SEPARATORLink to this heading#

Standard: '.' (punkt)

Standard decimalavskiljare som används vid formatering av decimaltal.

Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas i stället.

Se även NUMBER_GROUPING, THOUSAND_SEPARATOR och USE_THOUSAND_SEPARATOR.

STANDARD_AUTO_FÄLTLink to this heading#

Default: 'django.db.models.BigAutoField'

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.

To build an address with a display name from variable content, see Formatting email addresses.

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).

STANDARD_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).

TILLÅ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#

Default: '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.

EMAIL_FILE_PATHLink to this heading#

Standard: Ej definierad

Den katalog som används av file email backend för att lagra utdatafiler.

EMAIL_HOSTLink to this heading#

Standard: 'localhost'

Den värd som ska användas för att skicka e-post.

Se ä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).

For more complex scenarios, the SMTP EmailBackend can be subclassed to add root certificates to its ssl_context using 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.

FIL_UPPLADDNING_HANTERARELink to this heading#

Standard:

[
    "django.core.files.uploadhandler.MemoryFileUploadHandler",
    "django.core.files.uploadhandler.TemporaryFileUploadHandler",
]

En 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.

See Uppladdningshanterare for details.

FILE_UPLOAD_MAX_MEMORY_SIZELink to this heading#

Standard: 2621440 (dvs. 2,5 MB).

The maximum size (in bytes) that an upload will be before it gets streamed to the file system. See Uppladdningshanterare for details.

Se ä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.

Den 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.

See Uppladdningshanterare for details.

FÖ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.

Värdet måste vara ett heltal från 0 till 6, där 0 betyder söndag, 1 betyder måndag och så vidare.

FIXTURE_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.

Se Förse data med fixturer och Lastning av fixtur.

FORCERA_SKRIPTNAMNLink to this heading#

Standard: None

If not None, this will be used as the value of the SCRIPT_NAME environment variable in any HTTP request. This setting can be used to override the server-provided value of SCRIPT_NAME, which may be a rewritten version of the preferred value or not supplied at all. It is also used by django.setup() to set the URL resolver script prefix outside of the request/response cycle (e.g. in management commands and standalone scripts) to generate correct URLs when FORCE_SCRIPT_NAME is provided.

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:

• 'django.forms.renderers.DjangoTemplates`’``

• 'django.forms.renderers.Jinja2` '

• 'django.forms.renderers.TemplatesSetting` '

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/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py

Du kan också ange en lista med Python-sökvägar, t.ex.:

FORMAT_MODULE_PATH = [
    "mysite.formats",
    "some_app.formats",
]

Nä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.

Tillgängliga format är:

• DATE_FORMAT

• DATE_INPUT_FORMATS

• DATETIME_FORMAT,

• DATETIME_INPUT_FORMATS

• DECIMAL_SEPARATOR

• FÖRSTA_DAGEN_I_VECKAN

• MONTH_DAY_FORMAT

• NUMBER_GROUPING

• SHORT_DATE_FORMAT

• SHORT_DATETIME_FORMAT

• THOUSAND_SEPARATOR

• TIME_FORMAT

• TIME_INPUT_FORMATS

• YEAR_MONTH_FORMAT

”OVÄRDERLIGA 404-URLARLink to this heading#

Standard: [] (tom lista)

List of compiled regular expression objects describing URLs that should be ignored when reporting HTTP 404 errors via email (see Hur man hanterar felrapportering). Regular expressions are matched against request’s full paths, as returned by get_full_path() (including any query strings). Use this if your site does not provide a commonly requested file such as favicon.ico or 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:

• en applikationskonfigurationsklass (föredras), eller

• ett paket som innehåller en ansökan.

Lär dig mer om applikationskonfigurationer.

Nä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:

• Tillå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:

• Om 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.

LANGUAGE_COOKIE_AGELink to this heading#

Standard: None (upphör att gälla när webbläsaren stängs)

Språkcookiens ålder i sekunder.

LANGUAGE_COOKIE_DOMAINLink to this heading#

Standard: None

Den domän som ska användas för språkcookien. Ange detta till en sträng som "example.com" för domänöverskridande cookies, eller använd None för en standarddomäncookie.

Var försiktig när du uppdaterar den här inställningen på en produktionswebbplats. Om du uppdaterar den här inställningen för att aktivera domänöverskridande cookies på en webbplats som tidigare använde standarddomäncookies kommer befintliga användarcookies som har den gamla domänen inte att uppdateras. Detta kommer att leda till att webbplatsens användare inte kan byta språk så länge dessa cookies finns kvar. Det enda säkra och tillförlitliga alternativet för att utföra bytet är att ändra namnet på språkcookien permanent (via inställningen LANGUAGE_COOKIE_NAME) och lägga till en middleware som kopierar värdet från den gamla cookien till en ny och sedan raderar den gamla.

LANGUAGE_COOKIE_HTTPONLYLink to this heading#

Standard: False

Om flaggan HttpOnly ska användas för språkcookien. Om denna är inställd på True kommer JavaScript på klientsidan inte att kunna komma åt språkcookien.

Se SESSION_COOKIE_HTTPONLY för detaljer om HttpOnly.

SPRÅK_COOKIE_NAMNLink to this heading#

Standard: 'django_language'

Namnet på den cookie som ska användas för språkcookien. Detta kan vara vad du vill (så länge det skiljer sig från de andra cookienamnen i din applikation). Se Internationalisering och lokalisering.

LANGUAGE_COOKIE_PATHLink to this heading#

Standard: '/'

Den sökväg som anges i språkcookien. Denna bör antingen matcha URL-sökvägen i din Django-installation eller vara en överordnad del av den sökvägen.

Detta är användbart om du har flera Django-instanser som körs under samma värdnamn. De kan använda olika cookie-sökvägar och varje instans kommer bara att se sin egen språkcookie.

Var försiktig när du uppdaterar den här inställningen på en produktionsanläggning. Om du uppdaterar den här inställningen så att den använder en djupare sökväg än tidigare kommer befintliga användarcookies som har den gamla sökvägen inte att uppdateras. Detta leder till att webbplatsens användare inte kan byta språk så länge dessa cookies finns kvar. Det enda säkra och tillförlitliga alternativet för att utföra bytet är att ändra namnet på språkcookien permanent (via inställningen LANGUAGE_COOKIE_NAME) och att lägga till en middleware som kopierar värdet från den gamla cookien till en ny och sedan raderar den.

LANGUAGE_COOKIE_SAMESITELink to this heading#

Standard: None

Värdet på flaggan SameSite i språkcookien. Denna flagga förhindrar att cookien skickas i cross-site-begäranden.

Se SESSION_COOKIE_SAMESITE för detaljer om SameSite.

SPRÅK_COOKIE_SECURELink to this heading#

Standard: False

Om en säker cookie ska användas för språkcookien. Om detta är inställt på True kommer cookien att markeras som ”säker”, vilket innebär att webbläsare kan säkerställa att cookien endast skickas via en HTTPS-anslutning.

LANGUAGESLink 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.

Listan ä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.

Om 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:

from django.utils.translation import gettext_lazy as _

LANGUAGES = [
    ("de", _("German")),
    ("en", _("English")),
]

SPRÅ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.

Listan innehåller språkkoder för språk som skrivs från höger till vänster.

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. 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.

Exempel:

LOCALE_PATHS = [
    "/home/www/project/common_files/locale",
    "/var/local/translations/locale",
]

Django 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.

En 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.

LOGGING_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.

Om du anger LOGGING_CONFIG till None, hoppar du över konfigurationen av loggningsprocessen.

MAILERSLink to this heading#

Standard: Ej definierad

A dictionary containing the settings for all email backends to be used with Django. It is a nested dictionary that maps backend aliases to dictionaries containing each mailer’s backend import path and configuration options.

Exempel:

MAILERS = {
    "default": {
        "BACKEND": "django.core.mail.backends.smtp.EmailBackend",
        "OPTIONS": {
            "host": "smtp.example.net",
        },
    },
    "newsletters": {
        "BACKEND": "django.core.mail.backends.smtp.EmailBackend",
        "OPTIONS": {
            "host": "smtp.bulk-email-service.example.com",
            "username": os.environ["BULK_EMAIL_SERVICE_ACCOUNT_ID"],
            "password": os.environ["BULK_EMAIL_SERVICE_API_KEY"],
            "use_tls": True,
        },
    },
}

If you plan to send email through Django, configuring at least a "default" mailer is recommended. Any number of additional mailers may also be specified. Depending on which backend is used, other options may be required.

Setting MAILERS to an empty dictionary ({}) disables email sending and any attempt to send mail will raise MailerDoesNotExist.

See Configuring email for more information.

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.

Exempel: "/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.

MIGRATION_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:

{"blog": "blog.db_migrations"}

I 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.

Till 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”

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, 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.

Vanlig 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)

Observera att det lokalt dikterade formatet har högre prioritet och kommer att tillämpas i stället.

Se ä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

En 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.

django-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:

• All sessions if you are using any other session backend than django.contrib.sessions.backends.cache, or are using the default 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.

pOLICY FÖR SÄKER ÖPPNING AV URSPRUNGSKÄLLORLink to this heading#

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_CSPLink to this heading#

Default: {}

This setting defines the directives used by the ContentSecurityPolicyMiddleware, which generates and adds a Content-Security-Policy (CSP) header to all responses that do not already include one.

The Content-Security-Policy header instructs browsers to restrict which resources a page is allowed to load. A properly configured CSP can block content that violates defined rules, helping prevent cross-site scripting (XSS) and other content injection attacks by explicitly declaring trusted sources for content such as scripts, styles, images, fonts, and more.

The setting must be a mapping (typically a dictionary) of directive names to their values. Each key should be a valid CSP directive such as default-src or script-src. The corresponding value can be a list, tuple, or set of source expressions or URLs to allow for that directive. If a set is used, it will be automatically sorted to ensure consistent output in the generated headers.

This example illustrates the expected structure, using the constants defined in CSP constants:

from django.utils.csp import CSP

SECURE_CSP = {
    "default-src": [CSP.SELF],
    "img-src": ["data:", CSP.SELF, "https://images.example.com"],
    "frame-src": [CSP.NONE],
}

SECURE_CSP_REPORT_ONLYLink to this heading#

Default: {}

This setting is just like SECURE_CSP, but instead of enforcing the policy, it instructs the ContentSecurityPolicyMiddleware to apply a Content-Security-Policy-Report-Only header to responses, which allows browsers to monitor and report policy violations without blocking content. This is useful for testing and refining a policy before enforcement.

Most browsers log CSP violations to the developer console and can optionally send them to a reporting endpoint. To collect these reports, the report-uri directive must be defined (see Policy violation reports for more details).

As noted in the MDN documentation on Content-Security-Policy-Report-Only, the report-uri directive must be specified for reports to be sent; otherwise, the header has no reporting effect (other than logging to the browser’s developer tools console).

Following the example from the SECURE_CSP setting:

from django.utils.csp import CSP

SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    "img-src": ["data:", CSP.SELF, "https://images.example.com"],
    "frame-src": [CSP.NONE],
    "report-uri": "/my-site/csp/reports/",
}

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:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

Detta 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.

Observera 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

En 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:

SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}

SERVER_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.

To build an address with a display name from variable content, see Formatting email addresses.

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.

SIGNED_COOKIE_LEGACY_SALT_FALLBACKLink to this heading#

Standard: False

Controls whether get_signed_cookie() accepts cookies signed with Django’s historical signed-cookie salt derivation based on key + salt.

Set this to True to accept those legacy signed cookies in addition to cookies signed with Django’s current unambiguous signed-cookie salt derivation.

SIGNING_BACKENDLink to this heading#

Standard: 'django.core.signing.TimestampSigner'

Den backend som används för att signera cookies och andra data.

Se även dokumentationen Kryptografisk signering.

FÖ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.

FÖRVARINGARLink to this heading#

Standard:

{
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",
    },
}

En 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.

Förråd kan ha vilket alias du vill. Det finns dock två alias som har särskild betydelse:

• default 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 = {
    # ...
    "example": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
        "OPTIONS": {
            "location": "/example",
            "base_url": "/example/",
        },
    },
}

OPTIONS 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.

TASKSLink to this heading#

Standard:

{
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
    }
}

A dictionary containing the settings for all Task backends to be used with Django. It is a nested dictionary whose contents maps backend aliases to a dictionary containing the options for each backend.

The TASKS setting must configure a default backend; any number of additional backends may also be specified. Depending on which backend is used, other options may be required. The following options are available as standard.

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.

Här är en inställning som säger till Djangos mallmotor att ladda mallar från underkatalogen templates i varje installerat program:

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "APP_DIRS": True,
    },
]

Följande alternativ är tillgängliga för alla 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.

TEST_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.

Se ä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:

[
    "%H:%M:%S",  # '14:30:59'
    "%H:%M:%S.%f",  # '14:30:59.000200'
    "%H:%M",  # '14:30'
]

En 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.

Se ä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.

Observera 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.

Nä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_BLANK_CHOICE_DASHLink to this heading#

Standard: False

The default blank choice label in Select widgets was changed from "---------" to django.db.models.fields.BLANK_CHOICE_LABEL. Set this transitional setting to True to revert to the previous label.

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.

Se även TIME_ZONE och USE_I18N.

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.

URLIZE_ASSUME_HTTPSLink to this heading#

Standard: False

Set this transitional setting to True to opt into using HTTPS as the default protocol when none is provided in URLs processed by the urlize and urlizetrunc template filters during the Django 6.x release cycle.

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.

Till 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”

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, 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.

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.

AUTH_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.

LOGIN_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.

Används av PasswordResetConfirmView.

LÖSENORD_HASHERSLink to this heading#

Se Hur Django lagrar lösenord.

Standard:

[
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
    "django.contrib.auth.hashers.ScryptPasswordHasher",
]

AUTH_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.

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.

MEDDELANDE_LAGRINGLink to this heading#

Standard: 'django.contrib.messages.storage.fallback.FallbackStorage'

Styr var Django lagrar meddelandedata. Giltiga värden är:

• '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.

De 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.

MEDDELANDEN_TAGGARLink to this heading#

Standard:

{
    messages.DEBUG: "debug",
    messages.INFO: "info",
    messages.SUCCESS: "success",
    messages.WARNING: "warning",
    messages.ERROR: "error",
}

Detta anger mappningen av meddelandenivå till meddelandetagg, som vanligtvis återges som en CSS-klass i HTML. Om du anger ett värde kommer det att utöka standardvärdet. Detta innebär att du bara behöver ange de värden som du behöver åsidosätta. Se Visning av meddelanden ovan för mer information.

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.

SESSION_COOKIE_AGELink to this heading#

Standard: 1209600 (2 veckor, i sekunder)

Ålder för sessionscookies, i sekunder.

SESSION_COOKIE_DOMÄNLink to this heading#

Standard: None

Den domän som ska användas för sessionscookies. Ange detta till en sträng som "example.com" för domänöverskridande cookies, eller använd None för en standarddomäncookie.

Om du vill använda domänöverskridande cookies med CSRF_USE_SESSIONS måste du inkludera en inledande punkt (t.ex. ".example.com") för att CSRF-mellanvarans referer-kontroll ska fungera.

Var försiktig när du uppdaterar den här inställningen på en produktionswebbplats. Om du uppdaterar den här inställningen för att aktivera domänöverskridande cookies på en webbplats som tidigare använde standarddomäncookies kommer befintliga användares cookies att ställas in på den gamla domänen. Detta kan leda till att de inte kan logga in så länge dessa cookies finns kvar.

Denna inställning påverkar även cookies som ställs in av django.contrib.messages.

SESSION_COOKIE_HTTPONLYLink to this heading#

Standard: True

Om flaggan HttpOnly ska användas för sessionskakan. Om denna är inställd på True kommer JavaScript på klientsidan inte att kunna komma åt sessionscookien.

HttpOnly är en flagga som ingår i en Set-Cookie HTTP-svarshuvud. Den ingår i standarden RFC 6265 Section 4.1.2.6 för cookies och kan vara ett användbart sätt att minska risken för att ett skript på klientsidan får tillgång till skyddade cookie-data.

Detta gör det mindre trivialt för en angripare att eskalera en cross-site scripting-sårbarhet till fullständig kapning av en användares session. Det finns inte många bra skäl till att stänga av detta. Din kod bör inte läsa sessionskakor från JavaScript.

SESSION_COOKIE_NAMNLink to this heading#

Standard: 'sessionid'

Namnet på den cookie som ska användas för sessioner. Det kan vara vad du vill (så länge det skiljer sig från de andra cookienamnen i din applikation).

SESSION_COOKIE_PATHLink to this heading#

Standard: '/'

Den sökväg som anges i sessionskakan. Denna bör antingen matcha URL-sökvägen i din Django-installation eller vara överordnad den sökvägen.

Detta är användbart om du har flera Django-instanser som körs under samma värdnamn. De kan använda olika cookie-sökvägar, och varje instans kommer bara att se sin egen session cookie.

SESSION_COOKIE_SAMESITELink to this heading#

Standard: 'Lax'

Värdet på flaggan SameSite i sessionscookien. Denna flagga förhindrar att cookien skickas i cross-site requests, vilket förhindrar CSRF-attacker och omöjliggör vissa metoder för att stjäla sessionscookies.

Möjliga värden för inställningen är:

• 'Strict': förhindrar att cookien skickas från webbläsaren till målwebbplatsen i alla sammanhang med cross-site browsing, även när du följer en vanlig länk.

  För en GitHub-liknande webbplats skulle detta till exempel innebära att om en inloggad användare följer en länk till ett privat GitHub-projekt som publiceras på ett företags diskussionsforum eller via e-post, kommer GitHub inte att ta emot sessionskakan och användaren kommer inte att kunna komma åt projektet. En banks webbplats vill dock sannolikt inte tillåta att några transaktionssidor länkas från externa webbplatser, så flaggan ”Strict” skulle vara lämplig.

• 'Lax' (standard): ger en balans mellan säkerhet och användbarhet för webbplatser som vill behålla användarens inloggade session när användaren kommer från en extern länk.

  I GitHub-scenariot skulle sessionskakan tillåtas när man följer en vanlig länk från en extern webbplats och blockeras i CSRF-benägna förfrågningsmetoder (t.ex. POST).

• 'None' (sträng): sessionskakan skickas med alla förfrågningar på samma webbplats och mellan olika webbplatser.

• False: avaktiverar flaggan.

SESSION_COOKIE_SECURELink to this heading#

Standard: False

Om en säker cookie ska användas för sessionscookien. Om detta är inställt på True kommer cookien att markeras som ”säker”, vilket innebär att webbläsare kan se till att cookien endast skickas via en HTTPS-anslutning.

Det är ingen bra idé att låta den här inställningen vara avstängd eftersom en angripare kan fånga en okrypterad sessionskaka med en paketsniffer och använda kakan för att kapa användarens session.

SESSION_ENGINELink to this heading#

Standard: 'django.contrib.sessions.backends.db'

Styr var Django lagrar sessionsdata. Inkluderade motorer är:

• '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.

SESSION_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.

SESSION_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:

• 'django.contrib.sessions.serializers.JSONSerializer'

Se Serialisering av session för mer information.

SITE_IDLink to this heading#

Standard: Ej definierad

ID, 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.

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.

Du 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.

STATICFILES_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.:

STATICFILES_DIRS = [
    "/home/special.polls.com/polls/static",
    "/home/polls.com/polls/static",
    "/opt/webfiles/common",
]

Observera 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").

STATICFILES_DIRS = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]

<a href="{% static 'downloads/polls_20101022.tar.gz' %}">

STATISKA FILER_FINDERSLink to this heading#

Standard:

[
    "django.contrib.staticfiles.finders.FileSystemFinder",
    "django.contrib.staticfiles.finders.AppDirectoriesFinder",
]

Listan över Finder-backends som vet hur man hittar statiska filer på olika platser.

Standardinstä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.

CacheLink to this heading#

• CACHES

• CACHE_MIDDLEWARE_ALIAS

• CACHE_MIDDLEWARE_KEY_PREFIX

• CACHE_MIDDLEWARE_SECONDS

DatabasLink to this heading#

• DATABASER

• DATABASE_ROUTERS

• DEFAULT_INDEX_TABLESPACE

• DEFAULT_TABLESPACE

FelsökningLink to this heading#

• DEBUG

• DEBUG_PROPAGATE_EXCEPTIONS

E-postadressLink to this heading#

• ADMINS

• DEFAULT_CHARSET

• DEFAULT_FROM_EMAIL

• EMAIL_BACKEND

• EMAIL_FILE_PATH

• EMAIL_HOST

• EMAIL_HOST_PASSWORD

• EMAIL_HOST_USER

• EMAIL_PORT

• EMAIL_SSL_CERTFILE

• EMAIL_SSL_KEYFILE

• EMAIL_SUBJECT_PREFIX

• EMAIL_TIMEOUT

• EMAIL_USE_LOCALTIME

• EMAIL_USE_SSL

• EMAIL_USE_TLS

• MAILERS

• MANAGERS

• SERVER_EMAIL

FelrapporteringLink to this heading#

• DEFAULT_EXCEPTION_REPORTER

• DEFAULT_EXCEPTION_REPORTER_FILTER

• IGNORABLE_404_URLS

• MANAGERS

• SILENCED_SYSTEM_CHECKS

FiluppladdningarLink to this heading#

• FILE_UPLOAD_HANDLERS

• FILE_UPLOAD_MAX_MEMORY_SIZE

• FILE_UPLOAD_DIRECTORY_PERMISSIONS

• FILE_UPLOAD_PERMISSIONS

• FILE_UPLOAD_TEMP_DIR

• MEDIA_ROOT

• MEDIA_URL

• STORAGES

FormulärLink to this heading#

• FORM_RENDERER

• USE_BLANK_CHOICE_DASH

Globalisering (i18n/l10n`)Link to this heading#

HTTPLink to this heading#

• DATA_UPLOAD_MAX_MEMORY_SIZE

• DATA_UPLOAD_MAX_NUMBER_FIELDS

• DATA_UPLOAD_MAX_NUMBER_FILES

• DEFAULT_CHARSET

• DISALLOWED_USER_AGENTS

• FORCE_SCRIPT_NAME

• INTERNAL_IPS

• MIDDLEWARE

• Säkerhet

  • SECURE_CONTENT_TYPE_NOSNIFF

  • SECURE_CROSS_ORIGIN_OPENER_POLICY

  • SECURE_CSP

  • SECURE_CSP_REPORT_ONLY

  • SECURE_HSTS_INCLUDE_SUBDOMAINS

  • SECURE_HSTS_PRELOAD

  • SECURE_HSTS_SECONDS

  • SECURE_PROXY_SSL_HEADER

  • SECURE_REDIRECT_EXEMPT

  • SECURE_REFERRER_POLICY

  • SECURE_SSL_HOST

  • SECURE_SSL_REDIRECT

• SIGNED_COOKIE_LEGACY_SALT_FALLBACK

• SIGNING_BACKEND

• USE_X_FORWARDED_HOST

• USE_X_FORWARDED_PORT

• WSGI_APPLICATION

LoggningLink to this heading#

• LOGGING

• LOGGING_CONFIG

ModellerLink to this heading#

• ABSOLUTE_URL_OVERRIDES

• FIXTURE_DIRS

• INSTALLED_APPS

SäkerhetLink to this heading#

• Skydd mot Cross Site Request Forgery

  • CSRF_COOKIE_DOMAIN

  • CSRF_COOKIE_NAME

  • CSRF_COOKIE_PATH

  • CSRF_COOKIE_SAMESITE

  • CSRF_COOKIE_SECURE

  • CSRF_FAILURE_VIEW

  • CSRF_HEADER_NAME

  • CSRF_TRUSTED_ORIGINS

  • CSRF_USE_SESSIONS

• SECRET_KEY

• SECRET_KEY_FALLBACKS

• URLIZE_ASSUME_HTTPS

• X_FRAME_OPTIONS

SerialiseringLink to this heading#

• DEFAULT_CHARSET

• SERIALIZATION_MODULES

MallarLink to this heading#

• TEMPLATES

TestarLink to this heading#

• Databas: TEST

• TEST_NON_SERIALIZED_APPS

• TEST_RUNNER

URL:erLink to this heading#

• APPEND_SLASH

• PREPEND_WWW

• ROOT_URLCONF