---
title: "Inställningar"
version: 6.0
locale: sv
source: https://docs.djangoproject.com/sv/6.0/ref/settings/
canonical: https://djangodocs.dev/sv/6.0/ref/settings/
---
# Inställningar

- [Kärninställningar](#core-settings)
- [Auth](#auth)
- [Meddelanden](#messages)
- [Sessioner](#sessions)
- [Webbplatser](#sites)
- [Statiska filer](#static-files)
- [Aktuellt index för kärninställningar](#core-settings-topical-index)

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

## Kärninställningar

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

### `ABSOLUTE_URL_OVERRIDES`

Standard: `{}` (Tom ordbok)

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

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

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

### `ADMINS`

Standard: `[]` (tom lista)

En lista över alla personer som får meddelanden om kodfel. När [`DEBUG=False`](#std-setting-DEBUG) och [`AdminEmailHandler`](/sv/6.0/ref/logging/#django.utils.log.AdminEmailHandler) är konfigurerad i [`LOGGING`](#std-setting-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>']
```

> **Changed in Django 6.0**
>
> In older versions, required a list of (name, address) tuples.

### `TILLÅTNA_HOSTS`

Standard: `[]` (tom lista)

En lista med strängar som representerar de värd-/domännamn som denna Django-webbplats kan betjäna. Detta är en säkerhetsåtgärd för att förhindra [HTTP Host header attacks](/sv/6.0/topics/security/#host-headers-virtual-hosting), 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`](#std-setting-MIDDLEWARE)).

Django tillåter också [fullständigt kvalificerat domännamn (FQDN)](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) 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`](#std-setting-USE_X_FORWARDED_HOST) is enabled) does not match any value in this
list, the [`django.http.HttpRequest.get_host()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_host) method will raise
[`SuspiciousOperation`](/sv/6.0/ref/exceptions/#django.core.exceptions.SuspiciousOperation).

När [`DEBUG`](#std-setting-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](/sv/6.0/topics/testing/advanced/#topics-testing-advanced-multiple-hosts).

This validation only applies via [`get_host()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_host);
if your code accesses the `Host` header directly from `request.META` you
are bypassing this security protection.

### `TILLÄGG_SLASH`

Standard: `True`

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

Inställningen [`APPEND_SLASH`](#std-setting-APPEND_SLASH) används endast om [`CommonMiddleware`](/sv/6.0/ref/middleware/#django.middleware.common.CommonMiddleware) är installerad (se [Middleware](/sv/6.0/topics/http/middleware/)). Se även [`PREPEND_WWW`](#std-setting-PREPEND_WWW).

### `CACHES`

Standard:

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

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

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

#### `BACKEND`

Standard: `''` (tom sträng)

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

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

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

#### `NYCKEL_FUNKTION`

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

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

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

Se [cache-dokumentationen](/sv/6.0/topics/cache/#cache-key-transformation) för mer information.

#### `KEY_PREFIX`

Standard: `''` (tom sträng)

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

Se [cache-dokumentationen](/sv/6.0/topics/cache/#cache-key-prefixing) för mer information.

#### `LOCATION`

Standard: `''` (tom sträng)

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

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

#### `OPTIONS`

Standard: `None`

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

En del information om tillgängliga parametrar finns i [cache arguments](/sv/6.0/topics/cache/#cache-arguments)-dokumentationen. Mer information finns i dokumentationen för din backend-modul.

#### `TIMEOUT`

Standard: `300`

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

#### `VERSION`

Standard: `1`

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

Se [cache-dokumentationen](/sv/6.0/topics/cache/#cache-versioning) för mer information.

### `CACHE_MIDDLEWARE_ALIAS`

Standard: `'default'`

Den cacheanslutning som ska användas för [cache middleware](/sv/6.0/topics/cache/#the-per-site-cache).

### `CACHE_MIDDLEWARE_KEY_PREFIX`

Standard: `''` (tom sträng)

En sträng som kommer att prefixeras till cacheknapparna som genereras av [cache middleware](/sv/6.0/topics/cache/#the-per-site-cache). Detta prefix kombineras med inställningen [`KEY_PREFIX`](#std-setting-CACHES-KEY_PREFIX); det ersätter den inte.

Se [Djangos ramverk för cache](/sv/6.0/topics/cache/).

### `CACHE_MIDDLEWARE_SEKUNDER`

Standard: `600`

Standard heltal antal sekunder för att cachelagra en sida för [cache middleware](/sv/6.0/topics/cache/#the-per-site-cache).

Se [Djangos ramverk för cache](/sv/6.0/topics/cache/).

### `CSRF_COOKIE_AGE`

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_DOMAIN`

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](/sv/6.0/ref/csrf/#csrf-limitations).

### `CSRF_COOKIE_HTTPONLY`

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](/sv/6.0/howto/csrf/#acquiring-csrf-token-from-html) istället för [från cookien](/sv/6.0/howto/csrf/#acquiring-csrf-token-from-cookie).

Se [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) för detaljer om `HttpOnly`.

### `CSRF_COOKIE_NAME`

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](/sv/6.0/ref/csrf/).

### `CSRF_COOKIE_PATH`

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_SAMESITE`

Standard: `'Lax'`

Värdet på flaggan [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) i CSRF-cookien. Denna flagga förhindrar att cookien skickas i cross-site-begäranden.

Se [`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) för detaljer om `SameSite`.

### `CSRF_COOKIE_SECURE`

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_SESSIONS`

Standard: `False`

Om CSRF-token ska lagras i användarens session i stället för i en cookie. Det kräver användning av [`django.contrib.sessions`](/sv/6.0/topics/http/sessions/#module-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](/sv/6.0/ref/views/#error-views) kräver CSRF-token måste `` SessionMiddleware` `` visas i `` MIDDLEWARE` `` före alla middleware som kan ge upphov till ett undantag för att utlösa en felvy (t.ex. `` PermissionDenied` ``) om du använder `CSRF_USE_SESSIONS`. Se [Beställning av mellanprogramvara](/sv/6.0/ref/middleware/#middleware-ordering).

### `CSRF_FAILURE_VIEW`

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

En prickad sökväg till den vyfunktion som ska användas när en inkommande begäran avvisas av [CSRF-skydd](/sv/6.0/ref/csrf/). 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`](/sv/6.0/ref/request-response/#django.http.HttpResponseForbidden).

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

### `CSRF_HEADER_NAME`

Standard: `'HTTP_X_CSRFTOKEN'`

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

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

### `CSRF_TRUSTED_ORIGINS`

Standard: `[]` (tom lista)

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

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

För en [`secure`](/sv/6.0/ref/request-response/#django.http.HttpRequest.is_secure) osäker begäran som inte innehåller rubriken `Origin` måste begäran ha en rubrik `Referer` som matchar det ursprung som finns i rubriken `Host`.

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

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

### `DATABASER`

Standard: `{}` (Tom ordbok)

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

Inställningen [`DATABASES`](#std-setting-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`](#std-setting-DATABASE-ENGINE) nedan om hur du anger andra databastyper. Detta exempel är för PostgreSQL:

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

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

#### `ATOMISKA_FÖRFRÅGNINGAR`

Standard: `False`

Sätt detta till `True` för att paketera varje vy i en transaktion på denna databas. Se [Koppling av transaktioner till HTTP-förfrågningar](/sv/6.0/topics/db/transactions/#tying-transactions-to-http-requests).

#### `AUTOCOMMIT`

Standard: `True`

Sätt detta till `False` om du vill [inaktivera Djangos transaktionshantering](/sv/6.0/topics/db/transactions/#deactivate-transaction-management) och implementera din egen.

#### `ENGINE`

Standard: `''` (tom sträng)

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

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

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

#### `HOST`

Standard: `''` (tom sträng)

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

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

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

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

Om du använder PostgreSQL, som standard (tom [`HOST`](#std-setting-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`](#std-setting-HOST) till ’localhost’ eller ’127.0.0.1’ (’host’-raderna i `pg_hba.conf`). På Windows bör du alltid definiera [`HOST`](#std-setting-HOST), eftersom UNIX-domänuttag inte är tillgängliga.

#### `NAME`

Standard: `''` (tom sträng)

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

#### `CONN_MAX_AGE`

Standard: `0`

Livslängden för en databasanslutning, som ett heltal i sekunder. Använd `0` för att stänga databasanslutningar i slutet av varje begäran - Djangos historiska beteende - och `None` för obegränsad [persistent databasanslutningar](/sv/6.0/ref/databases/#persistent-database-connections).

#### `CONN_HÄLSOKONTROLLER`

Standard: `False`

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

#### `OPTIONS`

Standard: `{}` (Tom ordbok)

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

En del information om tillgängliga parametrar finns i dokumentationen [Database Backends](/sv/6.0/ref/databases/). För mer information, se din backendmoduls egen dokumentation.

#### `PASSWORD`

Standard: `''` (tom sträng)

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

#### `PORT`

Standard: `''` (tom sträng)

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

#### `TIME_ZONE`

Standard: `None`

En sträng som representerar tidszonen för denna databasanslutning eller `None`. Detta inre alternativ till inställningen [`DATABASES`](#std-setting-DATABASES) accepterar samma värden som den allmänna inställningen [`TIME_ZONE`](#std-setting-TIME_ZONE).

När [`USE_TZ`](#std-setting-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`](#std-setting-USE_TZ) är `False`, är det fel att ange detta alternativ.

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

  Om du ändrar tidszonen för anslutningen ändras hur datatider läses från och skrivs till databasen.

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

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

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

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

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

#### `AVAKTIVERA_SERVER_SIDE_CURSORS`

Standard: `False`

Ställ in detta på `True` om du vill inaktivera användningen av server-side cursors med [`QuerySet.iterator()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.iterator). [Transaktionspoolning och cursorer på serversidan](/sv/6.0/ref/databases/#transaction-pooling-server-side-cursors) beskriver användningsfallet.

Detta är en PostgreSQL-specifik inställning.

#### `USER`

Standard: `''` (tom sträng)

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

#### `TEST`

Standard: `{}` (Tom ordbok)

En ordbok med inställningar för testdatabaser; för mer information om hur testdatabaser skapas och används, se [Testdatabasen](/sv/6.0/topics/testing/overview/#the-test-database).

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

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

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

##### `CHARSET`

Standard: `None`

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

Stöds av [PostgreSQL](https://www.postgresql.org/docs/current/multibyte.html) (`postgresql`) och [MySQL](https://dev.mysql.com/doc/refman/en/charset-charsets.html) (`mysql`) backends.

##### `KOLLATION`

Standard: `None`

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

Stöds endast för `mysql` backend (se [MySQL manual](https://dev.mysql.com/doc/refman/en/charset-charsets.html) för detaljer).

##### bEROENDEN

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

Databasens beroenden i skapelseordningen. Se dokumentationen om [kontrollera skapelseordningen för testdatabaser](/sv/6.0/topics/testing/advanced/#topics-testing-creation-dependencies) för mer information.

##### `MIGRATE`

Standard: `True`

När värdet är satt till `False` kommer migreringar inte att köras när testdatabasen skapas. Detta liknar inställningen av `None` som ett värde i [`MIGRATION_MODULES`](#std-setting-MIGRATION_MODULES), men för alla appar.

##### `MIRROR`

Standard: `None`

Aliaset för den databas som denna databas ska spegla under testning. Den är beroende av transaktioner och måste därför användas inom [`TransactionTestCase`](/sv/6.0/topics/testing/tools/#django.test.TransactionTestCase) i stället för [`TestCase`](/sv/6.0/topics/testing/tools/#django.test.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](/sv/6.0/topics/testing/advanced/#topics-testing-primaryreplica).

##### `NAME`

Standard: `None`

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

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

Se testdatabasen.

##### `TEMPLATE`

Detta är en PostgreSQL-specifik inställning.

Namnet på en [template](https://www.postgresql.org/docs/current/sql-createdatabase.html) (t.ex. `'template0'`) från vilken testdatabasen ska skapas.

##### `CREATE_DB`

Standard: `True`

Detta är en Oracle-specifik inställning.

Om 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ÄNDARE`

Standard: `True`

Detta är en Oracle-specifik inställning.

Om den är inställd på `False` kommer testanvändaren inte att skapas automatiskt i början av testerna och tas bort i slutet.

##### `USER`

Standard: `None`

Detta är en Oracle-specifik inställning.

Anvä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`.

##### `PASSWORD`

Standard: `None`

Detta är en Oracle-specifik inställning.

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

##### `ORACLE_HANTERADE_FILER`

Standard: `False`

Detta är en Oracle-specifik inställning.

Om inställningen är `True` kommer Oracle Managed Files (OMF) tablespaces att användas. [`DATAFILE`](#std-setting-DATAFILE) och [`DATAFILE_TMP`](#std-setting-DATAFILE_TMP) kommer att ignoreras.

##### `TBLSPACE`

Standard: `None`

Detta är en Oracle-specifik inställning.

Namnet 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_TMP`

Standard: `None`

Detta är en Oracle-specifik inställning.

Namnet 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'`.

##### `DATAFILE`

Standard: `None`

Detta är en Oracle-specifik inställning.

Namnet på datafilen som ska användas för TBLSPACE. Om det inte anges kommer Django att använda `TBLSPACE + '.dbf'`.

##### `DATAFILE_TMP`

Standard: `None`

Detta är en Oracle-specifik inställning.

Namnet på datafilen som ska användas för TBLSPACE\_TMP. Om det inte anges kommer Django att använda `TBLSPACE_TMP + '.dbf'`.

##### `DATAFIL_MAXSTORLEK`

Standard: `'500M'`

Detta är en Oracle-specifik inställning.

Den maximala storlek som DATAFILE får växa till.

##### `DATAFIL_TMP_MAXSTORLEK`

Standard: `'500M'`

Detta är en Oracle-specifik inställning.

Den maximala storlek som DATAFILE\_TMP får växa till.

##### `DATAFIL_STORLEK`

Standard: `'50M'`

Detta är en Oracle-specifik inställning.

Den ursprungliga storleken på DATAFILE.

##### `DATAFIL_TMP_STORLEK`

Standard: `'50M'`

Detta är en Oracle-specifik inställning.

Den ursprungliga storleken på DATAFILE\_TMP.

##### `DATAFIL_EXTSTORLEK`

Standard: `'25M'`

Detta är en Oracle-specifik inställning.

Den mängd som DATAFILE utökas med när mer utrymme krävs.

##### `DATAFIL_TMP_EXTSIZE`

Standard: `'25M'`

Detta är en Oracle-specifik inställning.

Det belopp med vilket DATAFILE\_TMP utökas när mer utrymme krävs.

### `DATA_UPLOAD_MAX_MEMORY_SIZE`

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

The maximum size in bytes that a request body may be before a
[`SuspiciousOperation`](/sv/6.0/ref/exceptions/#django.core.exceptions.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`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE).

### `DATA_UPPLADDNING_MAX_ANTAL_FÄLT`

Standard: `1000`

Det maximala antalet parametrar som kan tas emot via GET eller POST innan en [`SuspiciousOperation`](/sv/6.0/ref/exceptions/#django.core.exceptions.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_FILES`

Standard: `100`

Det maximala antalet filer som kan tas emot via POST i en `multipart/form-data`-kodad begäran innan en [`SuspiciousOperation`](/sv/6.0/ref/exceptions/#django.core.exceptions.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_ROUTRAR`

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](/sv/6.0/topics/db/multi-db/#topics-db-multi-db-routing).

### `DATUM_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date).

Se även [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) och [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT).

### `DATUM_INMATNINGSFORMAT`

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](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), inte formatsträngarna från [`date`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date)-mallfiltret.

Det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället.

Se även [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) och [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS).

### `DATATID_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date).

Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) och [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT).

### `DATATID_INMATNINGSFORMAT`

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](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), inte formatsträngarna från [`date`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date)-mallfiltret. Format som endast innehåller datum ingår inte eftersom datetime-fält automatiskt kommer att prova [`DATE_INPUT_FORMATS`](#std-setting-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`](#std-setting-DATE_INPUT_FORMATS) och [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS).

### `DEBUG`

Standard: `False`

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

Driftsätt aldrig en webbplats i produktion med [`DEBUG`](#std-setting-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`](#std-setting-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`](#std-setting-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`](#std-setting-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`](#std-setting-DEBUG) är `False`, måste du också korrekt ställa in [`ALLOWED_HOSTS`](#std-setting-ALLOWED_HOSTS). Om du inte gör det kommer alla förfrågningar att returneras som ”Bad Request (400)”.

> **Note**
>
> Standardfilen `settings.py` som skapats av [`django-admin startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) anger `DEBUG = True` för enkelhetens skull.

### `DEBUG_PROPAGATE_EXCEPTIONS`

Standard: `False`

Om inställningen är `True` hoppas Djangos undantagshantering av vyfunktioner ([`handler500`](/sv/6.0/ref/urls/#django.conf.urls.handler500), eller debug-vyn om [`DEBUG`](#std-setting-DEBUG) är `True`) och loggning av 500-svar ([django.begäran](/sv/6.0/ref/logging/#django-request-logger)) ö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_SEPARATOR`

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`](#std-setting-NUMBER_GROUPING), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) och [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `STANDARD_AUTO_FÄLT`

Default: `'`[`django.db.models.BigAutoField`](/sv/6.0/ref/models/fields/#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`](/sv/6.0/ref/models/fields/#django.db.models.Field.primary_key).

> **Changed in Django 6.0**
>
> In older versions, the default value is
> [`django.db.models.AutoField`](/sv/6.0/ref/models/fields/#django.db.models.AutoField).

> **Migrering av automatiskt skapade genomgående tabeller**
>
> Värdet på `DEFAULT_AUTO_FIELD` kommer att respekteras när man skapar nya automatiskt skapade genomgående tabeller för många-till-många-relationer.
>
> Tyvärr kan primärnycklarna i befintliga automatiskt skapade genomgående tabeller för närvarande inte uppdateras av migreringsramverket.
>
> Det innebär att om du ändrar värdet på `DEFAULT_AUTO_FIELD` och sedan genererar migreringar, kommer primärnycklarna i de relaterade modellerna att uppdateras, liksom främmande nycklar från den genomgående tabellen, men primärnyckeln i den automatiskt skapade genomgående tabellen kommer inte att migreras.
>
> För att åtgärda detta bör du lägga till en [`RunSQL`](/sv/6.0/ref/migration-operations/#django.db.migrations.operations.RunSQL) operation till dina migreringar för att utföra det nödvändiga `ALTER TABLE` steget. Du kan kontrollera det befintliga tabellnamnet genom `qlmigrate`, `dbshell` eller med fältets egenskap `remote_field.through._meta.db_table`.
>
> Explicit definierade genomgående modeller hanteras redan av migreringssystemet.
>
> Tillåter automatisk migrering för primärnyckeln i befintliga automatiskt skapade genomgående tabeller [kan implementeras vid ett senare tillfälle](https://code.djangoproject.com/ticket/32674).

### `STANDARD_TECKENSNITT`

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ÖR`

Standard: `'``` django.views.debug.ExceptionReporter` `` `'`

Standardklass för undantagsrapportör som ska användas om ingen har tilldelats [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.HttpRequest)-instansen ännu. Se [Anpassade felrapporter](/sv/6.0/howto/error-reporting/#custom-error-reports).

### `STANDARD_FILTER_FÖR_AVVIKELSERAPPORTÖR`

Standard: `'``` django.views.debug.SafeExceptionReporterFilter` `` `'`

Standardfilterklass för undantagsrapporter som ska användas om ingen har tilldelats [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.HttpRequest)-instansen ännu. Se [Filtrering av felrapporter](/sv/6.0/howto/error-reporting/#filtering-error-reports).

### `STANDARD_FRÅN_EMAIL`

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`](#std-setting-ADMINS) och [`MANAGERS`](#std-setting-MANAGERS). Se [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL) för detta.

### `STANDARD_INDEX_TABLESPACE`

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](/sv/6.0/topics/db/tablespaces/)).

### `STANDARD_TABELLUTRYMME`

Standard: `''` (tom sträng)

Standard tablespace att använda för modeller som inte anger något, om backend stöder det (se [Bordsytor](/sv/6.0/topics/db/tablespaces/)).

### `TILLÅTNA_ANVÄNDARE_AGENTER`

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](/sv/6.0/topics/http/middleware/)).

### `EMAIL_BACKEND`

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](/sv/6.0/topics/email/#topic-email-backends).

### `EMAIL_FILE_PATH`

Standard: Ej definierad

Den katalog som används av [file email backend](/sv/6.0/topics/email/#topic-email-file-backend) för att lagra utdatafiler.

### `EMAIL_HOST`

Standard: `'localhost'`

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

Se även [`EMAIL_PORT`](#std-setting-EMAIL_PORT).

### `EMAIL_HOST_PASSWORD`

Standard: `''` (tom sträng)

Lösenord som ska användas för SMTP-servern som definieras i [`EMAIL_HOST`](#std-setting-EMAIL_HOST). Denna inställning används tillsammans med [`EMAIL_HOST_USER`](#std-setting-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`](#std-setting-EMAIL_HOST_USER).

### `EMAIL_HOST_USER`

Standard: `''` (tom sträng)

Användarnamn att använda för SMTP-servern som definieras i [`EMAIL_HOST`](#std-setting-EMAIL_HOST). Om det är tomt kommer Django inte att försöka autentisera.

Se även [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD).

### `EMAIL_PORT`

Standard: `25`

Port som ska användas för den SMTP-server som definieras i [`EMAIL_HOST`](#std-setting-EMAIL_HOST).

### `EMAIL_SUBJECT_PREFIX`

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_LOKALTID`

Standard: `False`

Om SMTP-rubriken `Date` för e-postmeddelanden ska skickas i den lokala tidszonen (`True`) eller i UTC (`False`).

### `EMAIL_USE_TLS`

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`](#std-setting-EMAIL_USE_SSL).

### `EMAIL_USE_SSL`

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`](#std-setting-EMAIL_USE_TLS).

Observera att [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS)/[`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) är ömsesidigt uteslutande, så sätt bara en av dessa inställningar till `True`.

### `EMAIL_SSL_CERTFILE`

Standard: `None`

Om [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) eller [`EMAIL_USE_TLS`](#std-setting-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`](#std-setting-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`](/sv/6.0/topics/email/#django.core.mail.backends.smtp.EmailBackend) subklassas för att lägga till rotcertifikat till dess `ssl_context` med [`ssl.SSLContext.load_verify_locations()`](https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locations).

### `EMAIL_SSL_KEYFILE`

Standard: `None`

Om [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) eller [`EMAIL_USE_TLS`](#std-setting-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`](#std-setting-EMAIL_SSL_CERTFILE).

Observera att inställningarna [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) och [`EMAIL_SSL_KEYFILE`](#std-setting-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()`](https://docs.python.org/3/library/ssl.html#ssl.SSLContext.wrap_socket) för detaljer om hur certifikatkedjefilen och den privata nyckelfilen hanteras.

### `EMAIL_TIMEOUT`

Standard: `None`

Anger en timeout i sekunder för blockering av åtgärder som anslutningsförsök.

### `FIL_UPPLADDNING_HANTERARE`

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](/sv/6.0/topics/http/file-uploads/#file-upload-handlers) for details.

### `FILE_UPLOAD_MAX_MEMORY_SIZE`

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](/sv/6.0/topics/http/file-uploads/#file-upload-handlers) for details.

Se även [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE).

### `FILE_UPLOAD_DIRECTORY_PERMISSIONS`

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`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) används. Se [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-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`](#std-setting-FILE_UPLOAD_PERMISSIONS).

### `FILE_UPLOAD_PERMISSIONS`

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()`](https://docs.python.org/3/library/os.html#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`](#std-setting-FILE_UPLOAD_TEMP_DIR).

Den här inställningen bestämmer också standardbehörigheterna för insamlade statiska filer när kommandot [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) används. Se [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) för information om hur du åsidosätter den.

> **Warning**
>
> **Föregå alltid läget med** `0o` **.**
>
> Om du inte är bekant med fillägen bör du notera att prefixet `0o` är mycket viktigt: det anger ett oktalt tal, vilket är det sätt som lägen måste anges på. Om du försöker använda `644` kommer du att få ett helt felaktigt beteende.

> **A numeric value trumps umask**
>
> When this setting has a numeric value (one you’ve set yourself, or the
> default `0o644`), this value will be used as is, and a umask will not
> be applied to it. The umask will apply only if this setting is `None`.

### `FILE_UPLOAD_TEMP_DIR`

Standard: `None`

Den katalog som data ska lagras i (vanligtvis filer som är större än [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-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](/sv/6.0/topics/http/file-uploads/#file-upload-handlers) for details.

### `FÖRSTA_DAGEN_I_VECKAN`

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_DIRS`

Standard: `[]` (tom lista)

Lista över kataloger som genomsökts efter [fixture](/sv/6.0/topics/db/fixtures/#fixtures-explanation)-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](/sv/6.0/howto/initial-data/#initial-data-via-fixtures) och [Lastning av fixtur](/sv/6.0/topics/testing/tools/#topics-testing-fixtures).

### `FORCERA_SKRIPTNAMN`

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()`](/sv/6.0/ref/applications/#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_RENDERER`

Standard: `'``` django.forms.renderers.DjangoTemplates` ``’

Klassen som renderar formulär och formulärwidgets. Den måste implementera [lågnivå rendering API](/sv/6.0/ref/forms/renderers/#low-level-widget-render-api). Inkluderade formulärrenderingar är:

- `'``` django.forms.renderers.DjangoTemplates` ``’\`\`
- `'``` django.forms.renderers.Jinja2` `` `'`
- `'``` django.forms.renderers.TemplatesSetting` `` `'`

### `FORMAT_MODUL_ SÖKVÄG`

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](/sv/6.0/topics/i18n/#term-locale-name)-notation, t.ex. `de`, `pt_BR`, `en_US`, etc.

Till exempel:, om [`FORMAT_MODULE_PATH`](#std-setting-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:

```text
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`](#std-setting-DATE_FORMAT)
- [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS)
- [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT),
- [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS)
- [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR)
- `FÖRSTA_DAGEN_I_VECKAN`
- [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT)
- [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING)
- [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT)
- [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT)
- [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR)
- [`TIME_FORMAT`](#std-setting-TIME_FORMAT)
- [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS)
- [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT)

### ”OVÄRDERLIGA 404-URLAR

Standard: `[]` (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](/sv/6.0/howto/error-reporting/)). Reguljära uttryck matchas mot [`requests fullständiga sökvägar`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_full_path) (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`](/sv/6.0/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) är aktiverat (se [Middleware](/sv/6.0/topics/http/middleware/)).

### `INSTALLERADE_APPAR`

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](/sv/6.0/ref/applications/).

> **Använd applikationsregistret för introspektion**
>
> Din kod ska aldrig komma åt [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) direkt. Använd [`django.apps.apps`](/sv/6.0/ref/applications/#django.apps.apps) istället.

> **Programnamn och etiketter måste vara unika i INSTALLED_APPS**
>
> Application [`names`](/sv/6.0/ref/applications/#django.apps.AppConfig.name) \- den prickade Python-sökvägen till applikationspaketet - måste vara unik. Det finns inget sätt att inkludera samma applikation två gånger, förutom att duplicera dess kod under ett annat namn.
>
> Application [`labels`](/sv/6.0/ref/applications/#django.apps.AppConfig.label) \- som standard den sista delen av namnet - måste också vara unik. Du kan till exempel inte inkludera både `django.contrib.auth` och `myproject.auth`. Du kan dock märka om en applikation med en anpassad konfiguration som definierar en annan [`label`](/sv/6.0/ref/applications/#django.apps.AppConfig.label).
>
> Dessa regler gäller oavsett om [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) refererar till programkonfigurationsklasser eller programpaket.

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`](#std-setting-INSTALLED_APPS) företräde.

### `INTERNA_IPS`

Standard: `[]` (tom lista)

En lista med IP-adresser, som strängar, som:

- Tillåt kontextprocessorn [`debug()`](/sv/6.0/ref/templates/api/#django.template.context_processors.debug) att lägga till några variabler i mallkontexten.
- Kan använda [admindocs bookmarklets](/sv/6.0/ref/contrib/admin/admindocs/#admindocs-bookmarklets) även om du inte är inloggad som personalanvändare.
- Markeras som ”intern” (i motsats till ”EXTERN”) i [`AdminEmailHandler`](/sv/6.0/ref/logging/#django.utils.log.AdminEmailHandler) e-postmeddelanden.

### `SPRÅK_KOD`

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](/sv/6.0/topics/i18n/#term-language-code). Till exempel: är U.S. English `"en-us"`. Se även [lista över språkidentifierare](http://www.i18nguy.com/unicode/language-identifiers.html) och [Internationalisering och lokalisering](/sv/6.0/topics/i18n/).

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`](/sv/6.0/topics/i18n/formatting/#std-templatefilter-unlocalize) eller taggen [`{% localize off %}`](/sv/6.0/topics/i18n/formatting/#std-templatetag-localize), tillhandahåller den reservformat för lokalisering som kommer att användas istället. Se [kontrollera lokalisering i mallar](/sv/6.0/topics/i18n/formatting/#topic-l10n-templates) för detaljer.

Se [Hur Django upptäcker språkpreferenser](/sv/6.0/topics/i18n/translation/#how-django-discovers-language-preference) för mer information.

### `LANGUAGE_COOKIE_AGE`

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

Språkcookiens ålder i sekunder.

### `LANGUAGE_COOKIE_DOMAIN`

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`](#std-setting-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_HTTPONLY`

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`](#std-setting-SESSION_COOKIE_HTTPONLY) för detaljer om `HttpOnly`.

### `SPRÅK_COOKIE_NAMN`

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](/sv/6.0/topics/i18n/).

### `LANGUAGE_COOKIE_PATH`

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`](#std-setting-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_SAMESITE`

Standard: `None`

Värdet på flaggan [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) i språkcookien. Denna flagga förhindrar att cookien skickas i cross-site-begäranden.

Se [`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) för detaljer om `SameSite`.

### `SPRÅK_COOKIE_SECURE`

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.

### `LANGUAGES`

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](https://github.com/django/django/blob/stable/6.0.x/django/conf/global_settings.py).

Listan är en lista med 2-tuples i formatet ([språkkod](/sv/6.0/topics/i18n/#term-language-code), `språknamn`) – till exempel `('ja', 'japanska')`. Detta anger vilka språk som är tillgängliga för språkval. Se [Internationalisering och lokalisering](/sv/6.0/topics/i18n/).

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`](#std-setting-LANGUAGES)-inställning kan du markera språknamnen som översättningssträngar med [`gettext_lazy()`](/sv/6.0/ref/utils/#django.utils.translation.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_BIDI`

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](https://github.com/django/django/blob/stable/6.0.x/django/conf/global_settings.py).

Listan innehåller [språkkoder](/sv/6.0/topics/i18n/#term-language-code) 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`](#std-setting-LANGUAGES)-inställning kan listan över dubbelriktade språk innehålla språkkoder som inte är aktiverade på en viss webbplats.

### `LOKALA SÖKVÄGAR`

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.

### `LOGGING`

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`](#std-setting-LOGGING_CONFIG).

Standardkonfigurationen för loggning skickar bland annat HTTP 500-serverfel till en e-postlogghanterare när [`DEBUG`](#std-setting-DEBUG) är `False`. Se även [Konfigurera loggning](/sv/6.0/topics/logging/#configuring-logging).

Du kan se standardkonfigurationen för loggning genom att titta i [django/utils/log.py](https://github.com/django/django/blob/stable/6.0.x/django/utils/log.py).

### `LOGGING_CONFIG`

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](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) konfigurationsmetod som standard.

Om du anger [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) till `None`, hoppar du över konfigurationen av loggningsprocessen.

### `FÖRVALTARE`

Standard: `[]` (tom lista)

En lista i samma format som [`ADMINS`](#std-setting-ADMINS) som anger vem som ska få meddelanden om brutna länkar när [`BrokenLinkEmailsMiddleware`](/sv/6.0/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) är aktiverat.

> **Changed in Django 6.0**
>
> In older versions, required a list of (name, address) tuples.

### `MEDIA_ROOT`

Standard: `''` (tom sträng)

Absolut filsystemssökväg till den katalog som ska innehålla [user-uploaded files](/sv/6.0/topics/files/).

Exempel: `"/var/www/example.com/media/"`

Se även [`MEDIA_URL`](#std-setting-MEDIA_URL).

> **Warning**
>
> [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) och [`STATIC_ROOT`](#std-setting-STATIC_ROOT) måste ha olika värden. Innan [`STATIC_ROOT`](#std-setting-STATIC_ROOT) introducerades var det vanligt att förlita sig på eller använda [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) för att även servera statiska filer; eftersom detta kan ha allvarliga säkerhetsimplikationer finns det dock en valideringskontroll för att förhindra det.

### `MEDIA_URL`

Standard: `''` (tom sträng)

URL som hanterar media som serveras från [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT), används för [hantering av lagrade filer](/sv/6.0/topics/files/). 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](/sv/6.0/howto/static-files/#serving-uploaded-files-in-development) 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`](#std-setting-TEMPLATES).

Exempel: `"https://media.example.com/"`

> **Warning**
>
> Det finns säkerhetsrisker om du accepterar uppladdat innehåll från icke betrodda användare! Se säkerhetsguidens ämne om [Innehåll som laddats upp av användare](/sv/6.0/topics/security/#user-uploaded-content-security) för mer information om begränsning.

> **Warning**
>
> [`MEDIA_URL`](#std-setting-MEDIA_URL) och [`STATIC_URL`](#std-setting-STATIC_URL) måste ha olika värden. Se [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) för mer information.

> **Note**
>
> Om [`MEDIA_URL`](#std-setting-MEDIA_URL) är en relativ sökväg kommer den att föregås av det servertillhandahållna värdet för `SCRIPT_NAME` (eller `/` om det inte är angivet). Detta gör det enklare att servera en Django-applikation i en underväg utan att lägga till en extra konfiguration i inställningarna.

### `MIDDLEWARE`

Standard: `None`

En lista över mellanprogram som ska användas. Se [Middleware](/sv/6.0/topics/http/middleware/).

### `MIGRATION_MODULES`

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`](/sv/6.0/ref/django-admin/#django-admin-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`](#std-setting-TEST_MIGRATE) till `False`. Om `MIGRATION_MODULES` används i dina allmänna projektinställningar, kom ihåg att använda alternativet [`migrate --run-syncdb`](/sv/6.0/ref/django-admin/#cmdoption-migrate-run-syncdb) om du vill skapa tabeller för appen.

### `MÅNAD_DAG_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date). Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) och [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT).

### `NUMMER_GRUPPERING`

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`](#std-setting-DECIMAL_SEPARATOR), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) och [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `PREPEND_WWW`

Standard: `False`

Om ”www.”-underdomänen ska läggas till i URL:er som inte har det. Detta används endast om [`CommonMiddleware`](/sv/6.0/ref/middleware/#django.middleware.common.CommonMiddleware) är installerat (se [Middleware](/sv/6.0/topics/http/middleware/)). Se även [`APPEND_SLASH`](#std-setting-APPEND_SLASH).

### `ROOT_URLCONF`

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](/sv/6.0/topics/http/urls/#how-django-processes-a-request) för detaljer.

### `SECRET_KEY`

Standard: `''` (tom sträng)

En hemlig nyckel för en viss Django-installation. Den används för att tillhandahålla [kryptografisk signering](/sv/6.0/topics/signing/), och bör sättas till ett unikt, oförutsägbart värde.

[`django-admin startproject`](/sv/6.0/ref/django-admin/#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()`](/sv/6.0/ref/utils/#django.utils.encoding.force_str) eller [`force_bytes()`](/sv/6.0/ref/utils/#django.utils.encoding.force_bytes) för att konvertera den till önskad typ.

Django kommer att vägra att starta om [`SECRET_KEY`](#std-setting-SECRET_KEY) inte är inställd.

> **Warning**
>
> **Håll detta värde hemligt.**
>
> Att köra Django med en känd [`SECRET_KEY`](#std-setting-SECRET_KEY) motverkar många av Djangos säkerhetsskydd och kan leda till privilegieeskalering och sårbarheter för fjärrkörning av kod.

Den hemliga nyckeln används för:

- All [sessions](/sv/6.0/topics/http/sessions/) if you are using
  any other session backend than `django.contrib.sessions.backends.cache`,
  or are using the default
  [`get_session_auth_hash()`](/sv/6.0/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash).
- Alla [messages](/sv/6.0/ref/contrib/messages/) om du använder [`CookieStorage`](/sv/6.0/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) eller [`FallbackStorage`](/sv/6.0/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage).
- Alla [`PasswordResetView`](/sv/6.0/topics/auth/default/#django.contrib.auth.views.PasswordResetView) tokens.
- All användning av [kryptografisk signering](/sv/6.0/topics/signing/), såvida inte en annan nyckel anges.

När en hemlig nyckel inte längre är inställd som [`SECRET_KEY`](#std-setting-SECRET_KEY) eller finns i [`SECRET_KEY_FALLBACKS`](#std-setting-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`](#std-setting-SECRET_KEY_FALLBACKS) tillfälligt. Hemliga nycklar används inte för användares lösenord och nyckelrotation påverkar inte dem.

> **Note**
>
> Standardfilen `settings.py` som skapas av [`django-admin startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) skapar en unik `SECRET_KEY` för enkelhetens skull.

### `SEKRETESS_NYCKEL_FALLBACK`

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.

> **Note**
>
> Signeringsoperationer är beräkningsmässigt dyra. Om du har flera gamla nyckelvärden i `SECRET_KEY_FALLBACKS` läggs ytterligare overhead till alla kontroller som inte matchar en tidigare nyckel.
>
> Därför bör reservvärden tas bort efter en lämplig tidsperiod, vilket möjliggör nyckelrotation.

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()`](/sv/6.0/ref/utils/#django.utils.encoding.force_str) eller [`force_bytes()`](/sv/6.0/ref/utils/#django.utils.encoding.force_bytes) för att konvertera den till önskad typ.

### `SECURE_CONTENT_TYPE_NOSNIFF`

Standard: `True`

Om `True`, ställer [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) in [X-Content-Type-Options: nosniff](/sv/6.0/ref/middleware/#x-content-type-options)-huvudet på alla svar som inte redan har det.

### pOLICY FÖR SÄKER ÖPPNING AV URSPRUNGSKÄLLOR

Standard: `'same-origin'`

Om den inte är inställd på `None`, ställer [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) in [Policy för öppnare för flera ursprung](/sv/6.0/ref/middleware/#cross-origin-opener-policy)-huvudet på alla svar som inte redan har det till det angivna värdet.

### `SECURE_CSP`

> **New in Django 6.0**

Default: `{}`

This setting defines the directives used by the
[`ContentSecurityPolicyMiddleware`](/sv/6.0/ref/middleware/#django.middleware.csp.ContentSecurityPolicyMiddleware), which
generates and adds a [Content-Security-Policy](/sv/6.0/ref/csp/#csp-overview) (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](/sv/6.0/ref/csp/#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],
}
```

> **Directives validation**
>
> Django’s CSP middleware helps construct and send the appropriate header
> based on your settings, but it does **not validate** that the directives and
> values conform to the CSP specification. It is your responsibility to ensure
> that the configuration is syntactically and semantically correct. Use
> browser developer tools or external CSP validators during development.
>
> For a list of available directives and their values, refer to the [MDN
> documentation on CSP directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives).

### `SECURE_CSP_REPORT_ONLY`

> **New in Django 6.0**

Default: `{}`

This setting is just like [`SECURE_CSP`](#std-setting-SECURE_CSP), but instead of enforcing the
policy, it instructs the
[`ContentSecurityPolicyMiddleware`](/sv/6.0/ref/middleware/#django.middleware.csp.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](/sv/6.0/ref/csp/#csp-reports) for more details).

As noted in the [MDN documentation on Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/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`](#std-setting-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_SUBDOMAINS`

Standard: `False`

Om `True`, lägger [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) till direktivet `includeSubDomains` till [HTTP Strict Transport Security](/sv/6.0/ref/middleware/#http-strict-transport-security)-huvudet. Det har ingen effekt om inte [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) är satt till ett värde som inte är noll.

> **Warning**
>
> Om du ställer in detta felaktigt kan det oåterkalleligen (för värdet på [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS)) förstöra din webbplats. Läs [HTTP Strict Transport Security](/sv/6.0/ref/middleware/#http-strict-transport-security)-dokumentationen först.

### `SÄKER_HSTS_FÖRLADDNING`

Standard: `False`

Om `True`, lägger [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) till `preload`-direktivet till [HTTP Strict Transport Security](/sv/6.0/ref/middleware/#http-strict-transport-security)-huvudet. Det har ingen effekt om inte [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) är satt till ett värde som inte är noll.

### `SECURE_HSTS_SEKUNDER`

Standard: `0`

Om det anges till ett heltal som inte är noll anger [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) [HTTP Strict Transport Security](/sv/6.0/ref/middleware/#http-strict-transport-security)-huvudet på alla svar som inte redan har det.

> **Warning**
>
> Om du ställer in detta felaktigt kan det oåterkalleligen (under en tid) förstöra din webbplats. Läs [HTTP Strict Transport Security](/sv/6.0/ref/middleware/#http-strict-transport-security)-dokumentationen först.

### `SECURE_PROXY_SSL_HEADER`

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

> **Warning**
>
> **Om du ändrar den här inställningen kan webbplatsens säkerhet äventyras. Se till att du förstår din inställning helt innan du ändrar den.**
>
> Kontrollera att ALLA följande är sanna innan du ställer in detta (med värdena från exemplet ovan):
>
> - Din Django-app befinner sig bakom en proxy.
> - Din proxy tar bort rubriken `X-Forwarded-Proto` från alla inkommande förfrågningar, även om den innehåller en kommaseparerad lista över protokoll. Med andra ord, om slutanvändare inkluderar den här rubriken i sina förfrågningar kommer proxyn att kasta bort den.
> - Din proxy ställer in rubriken `X-Forwarded-Proto` och skickar den till Django, men endast för förfrågningar som ursprungligen kommer in via HTTPS.
>
> Om något av dessa inte stämmer bör du låta denna inställning vara inställd på ”Ingen” och hitta ett annat sätt att fastställa HTTPS, kanske via anpassad middleware.

### `SÄKER_OMDIRIGERING_BEFRIAD`

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`](/sv/6.0/ref/middleware/#django.middleware.security.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`](#std-setting-SECURE_SSL_REDIRECT) är `False` har denna inställning ingen effekt.

### `POLICY FÖR SÄKRA REFERENSER` `SECURE_REFERRER_POLICY`

Standard: `'same-origin'`

Om den konfigureras ställer [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) in [Policy för hänvisare](/sv/6.0/ref/middleware/#referrer-policy)-huvudet på alla svar som inte redan har det till det angivna värdet.

### `SECURE_SSL_HOST`

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`](#std-setting-SECURE_SSL_REDIRECT) är `False` har denna inställning ingen effekt.

### `SÄKER_SSL_OMDIRIGERING`

Standard: `False`

Om `True`, [`SecurityMiddleware`](/sv/6.0/ref/middleware/#django.middleware.security.SecurityMiddleware) [redirects](/sv/6.0/ref/middleware/#ssl-redirect) 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`](#std-setting-SECURE_REDIRECT_EXEMPT)).

> **Note**
>
> Om inställningen `True` orsakar oändliga omdirigeringar betyder det förmodligen att din webbplats körs bakom en proxy och inte kan avgöra vilka förfrågningar som är säkra och vilka som inte är det. Din proxy ställer sannolikt in ett huvud för att indikera säkra förfrågningar; du kan åtgärda problemet genom att ta reda på vad det är för huvud och konfigurera [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER)-inställningen i enlighet med detta.

### `SERIALIZATION_MODULES`

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_EMAIL`

Standard: `'root@localhost'`

E-postadressen som felmeddelanden kommer från, t.ex. de som skickas till [`ADMINS`](#std-setting-ADMINS) och [`MANAGERS`](#std-setting-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.

> **Varför skickas mina e-postmeddelanden från en annan adress?**
>
> Denna adress används endast för felmeddelanden. Det är *inte* den adress som vanliga e-postmeddelanden som skickas med [`send_mail()`](/sv/6.0/topics/email/#django.core.mail.send_mail) kommer från; för det, se [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL).

### `KORT_DATUM_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date).

Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT) och [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT).

### `KORT_DATATID_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date).

Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT) och [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT).

### `SIGNED_COOKIE_LEGACY_SALT_FALLBACK`

> **New in Django 5.2.15**

Standard: `True`

Controls whether [`get_signed_cookie()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_signed_cookie) accepts
cookies signed with Django’s historical signed-cookie salt derivation based on
`key + salt`.

Set this to `False` to reject those legacy signed cookies and only accept
cookies signed with Django’s current unambiguous signed-cookie salt derivation.
This transitional setting will be removed in Django 7.0, when the legacy signed
cookies will no longer be accepted.

### `SIGNING_BACKEND`

Standard: `'django.core.signing.TimestampSigner'`

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

Se även dokumentationen [Kryptografisk signering](/sv/6.0/topics/signing/).

### `FÖRSVAGADE_SYSTEMKONTROLLER`

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](/sv/6.0/ref/checks/).

### `FÖRVARINGAR`

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](/sv/6.0/topics/files/). `'`[`django.core.files.storage.FileSystemStorage`](/sv/6.0/ref/files/storage/#django.core.files.storage.FileSystemStorage)`'` är standardlagringsmotorn.
- `staticfiles` för [hantera statiska filer](/sv/6.0/ref/contrib/staticfiles/). `'``` 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`](/sv/6.0/ref/files/storage/#django.core.files.storage.storages). Använd en nyckel som motsvarar backend-definitionen i [`STORAGES`](#std-setting-STORAGES).

> **Är mitt värde sammanfogat med standardvärdet?**
>
> Om du definierar den här inställningen åsidosätts standardvärdet och slås *inte* samman med det.

### `TASKS`

> **New in Django 6.0**

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`](#std-setting-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.

#### `BACKEND`

Standard: `''` (tom sträng)

The Tasks backend to use. The built-in backends are:

- `'django.tasks.backends.dummy.DummyBackend'`
- `'django.tasks.backends.immediate.ImmediateBackend'`

You can use a backend that doesn’t ship with Django by setting
[`BACKEND`](#std-setting-TASKS-BACKEND) to a fully-qualified path of a backend
class (i.e. `mypackage.backends.whatever.WhateverBackend`).

#### `QUEUES`

Default: `["default"]`

Specify the queue names supported by the backend. This can be used to ensure
Tasks aren’t enqueued to queues which do not exist.

To disable queue name validation, set to an empty list (`[]`).

#### `OPTIONS`

Default: `{}`

Extra parameters to pass to the Task backend. Available parameters vary
depending on the Task backend.

### `TEMPLATES`

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.

#### `BACKEND`

Standard: Ej definierad

Den mallbackend som ska användas. De inbyggda mallbackendsen är:

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

#### `NAME`

Standard: se nedan

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

Det är standardnamnet på modulen som definierar motorklassen, dvs. den näst sista delen av [`BACKEND`](#std-setting-TEMPLATES-BACKEND), om det inte anges. Till exempel: om backend är `'mypackage.whatever.Backend'` så är dess standardnamn `'whatever'`.

#### `DIRS`

Standard: `[]` (tom lista)

Kataloger där sökmotorn ska leta efter mallens källfiler, i sökordning.

#### `APP_DIRS`

Standard: `False`

Om sökmotorn ska leta efter mallkällfiler i installerade program.

> **Note**
>
> Standardfilen `settings.py` som skapades av [`django-admin startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) ställer in `'APP_DIRS': True`.

#### `OPTIONS`

Standard: `{}` (Tom dikt)

Extra parametrar att skicka till mallens backend. Tillgängliga parametrar varierar beroende på mallens backend. Se [`DjangoTemplates`](/sv/6.0/topics/templates/#django.template.backends.django.DjangoTemplates) och [`Jinja2`](/sv/6.0/topics/templates/#django.template.backends.jinja2.Jinja2) för alternativen för de inbyggda backends.

### `TEST_RUNNER`

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_APPS`

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](/sv/6.0/topics/testing/overview/#test-case-serialized-rollback) 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_SEPARATOR`

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`](#std-setting-USE_THOUSAND_SEPARATOR) är `True` och [`NUMBER_GROUPING`](#std-setting-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`](#std-setting-NUMBER_GROUPING), [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) och [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR).

### `TID_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date).

Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT) och [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT).

### `TID_INMATNINGSFORMAT`

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](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), inte formatsträngarna från [`date`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date)-mallfiltret.

Det lokalt dikterade formatet har högre prioritet och kommer att tillämpas istället.

Se även [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) och [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS).

### `TIME_ZONE`

Standard: `'Amerika/Chicago'`

En sträng som representerar tidszonen för den här installationen. Se [lista över tidszoner](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

> **Note**
>
> Eftersom Django först släpptes med [`TIME_ZONE`](#std-setting-TIME_ZONE) inställd på `'America/Chicago`, är den globala inställningen (som används om inget är definierat i ditt projekts `settings.py`) fortfarande `'America/Chicago` för bakåtkompatibilitet. Nya projektmallar använder som standard `'UTC'`.

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`](#std-setting-USE_TZ) är `False`, är detta den tidszon som Django kommer att lagra alla datatider i. När [`USE_TZ`](#std-setting-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()`](https://docs.python.org/3/library/time.html#time.tzset) är implementerad) ställer Django in variabeln `os.environ['TZ']` till den tidszon som du anger i inställningen [`TIME_ZONE`](#std-setting-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](/sv/6.0/topics/settings/#settings-without-django-settings-module). 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ö.

> **Note**
>
> Django kan inte på ett tillförlitligt sätt använda alternativa tidszoner i en Windows-miljö. Om du kör Django på Windows måste [`TIME_ZONE`](#std-setting-TIME_ZONE) ställas in så att den matchar systemets tidszon.

### `USE_I18N`

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`](#std-setting-LANGUAGE_CODE) och [`USE_TZ`](#std-setting-USE_TZ).

> **Note**
>
> Standardfilen `settings.py` som skapats av [`django-admin startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) innehåller `USE_I18N = True` för enkelhetens skull.

### `ANVÄNDA_TUSENTALS_SEPARATOR`

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`](#std-setting-NUMBER_GROUPING) och [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR). De två sistnämnda inställningarna kan också dikteras av lokalen, som har företräde.

Se även [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) och [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR).

### `USE_TZ`

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`](#std-setting-TIME_ZONE) och [`USE_I18N`](#std-setting-USE_I18N).

### `USE_X_FORWARDED_HOST`

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`](#std-setting-USE_X_FORWARDED_PORT). Enligt [**RFC 7239 Section 5.3**](https://datatracker.ietf.org/doc/html/rfc7239.html#section-5.3) kan rubriken `X-Forwarded-Host` innehålla portnumret, i vilket fall du inte bör använda [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT).

### `USE_X_FORWARDED_PORT`

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`](#std-setting-USE_X_FORWARDED_HOST) har prioritet över denna inställning.

### `URLIZE_ASSUME_HTTPS`

> **New in Django 6.0**

> **Deprecated since Django 6.0**
>
> Ersatt sedan version 6.0.

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-urlize) and [`urlizetrunc`](/sv/6.0/ref/templates/builtins/#std-templatefilter-urlizetrunc) template filters during the Django
6.x release cycle.

### `WSGI_APPLIKATION`

Standard: `None`

Den fullständiga Python-sökvägen till WSGI-applikationsobjektet som Djangos inbyggda servrar (t.ex. [`runserver`](/sv/6.0/ref/django-admin/#django-admin-runserver)) kommer att använda. Ledningskommandot [`django-admin startproject`](/sv/6.0/ref/django-admin/#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`](/sv/6.0/ref/django-admin/#django-admin-runserver) att vara identiskt med tidigare Django-versioner.

### `ÅR_MÅNAD_FORMAT`

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`](/sv/6.0/ref/templates/builtins/#std-templatefilter-date). Se även [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) och [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT).

### `X_FRAME_OPTIONS`

Standard: `'DENY'`

Standardvärdet för X-Frame-Options-huvudet som används av [`XFrameOptionsMiddleware`](/sv/6.0/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware). Se dokumentationen för [clickjacking protection](/sv/6.0/ref/clickjacking/).

## Auth

Inställningar för [`django.contrib.auth`](/sv/6.0/topics/auth/#module-django.contrib.auth).

### `AUTENTICATION_BACKENDS`

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](/sv/6.0/topics/auth/customizing/#authentication-backends) för mer information.

### `AUTH_USER_MODEL`

Standard: `'auth.User'`

Den modell som ska användas för att representera en användare. Se [Ersätta en anpassad User-modell](/sv/6.0/topics/auth/customizing/#auth-custom-user).

> **Warning**
>
> Du kan inte ändra AUTH\_USER\_MODEL-inställningen under ett projekts livstid (dvs. när du har skapat och migrerat modeller som är beroende av den) utan stora ansträngningar. Den är avsedd att ställas in vid projektstart, och modellen som den hänvisar till måste vara tillgänglig vid den första migreringen av appen som den finns i. Se [Ersätta en anpassad User-modell](/sv/6.0/topics/auth/customizing/#auth-custom-user) för mer information.

### `LOGIN_REDIRECT_URL`

Standard: `'/accounts/profile/'`

URL:en eller [namngivet URL-mönster](/sv/6.0/topics/http/urls/#naming-url-patterns) dit förfrågningar omdirigeras efter inloggning när [`LoginView`](/sv/6.0/topics/auth/default/#django.contrib.auth.views.LoginView) inte får någon `next` GET-parameter.

### `LOGIN_URL`

Standard: `'/accounts/login/'`

URL:en eller [namngivet URL-mönster](/sv/6.0/topics/http/urls/#naming-url-patterns) där förfrågningar omdirigeras för inloggning när man använder [`login_required()`](/sv/6.0/topics/auth/default/#django.contrib.auth.decorators.login_required) decorator, [`LoginRequiredMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.LoginRequiredMixin), [`AccessMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.AccessMixin), eller när [`LoginRequiredMiddleware`](/sv/6.0/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware) är installerad.

### `LOGOUT_REDIRECT_URL`

Standard: `None`

URL:en eller [namngivet URL-mönster](/sv/6.0/topics/http/urls/#naming-url-patterns) dit förfrågningar omdirigeras efter utloggning om [`LogoutView`](/sv/6.0/topics/auth/default/#django.contrib.auth.views.LogoutView) inte har attributet `next_page`.

Om `None`, kommer ingen omdirigering att utföras och logout-vyn kommer att återges.

### `LÖSENORD_ÅTERSTÄLL_TIMEOUT`

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`](/sv/6.0/topics/auth/default/#django.contrib.auth.views.PasswordResetConfirmView).

> **Note**
>
> Att minska värdet på denna timeout gör ingen skillnad för en angripares möjlighet att brute-forcea en token för återställning av lösenord. Tokens är utformade för att vara säkra från brute-forcing utan någon timeout.
>
> Denna timeout finns för att skydda mot vissa osannolika attackscenarier, t.ex. att någon får tillgång till e-postarkiv som kan innehålla gamla, oanvända lösenordsåterställningstoken.

### `LÖSENORD_HASHERS`

Se [Hur Django lagrar lösenord](/sv/6.0/topics/auth/passwords/#auth-password-storage).

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_VALIDATORER`

Standard: `[]` (tom lista)

Listan över validerare som används för att kontrollera styrkan i användarens lösenord. Se [Validering av lösenord](/sv/6.0/topics/auth/passwords/#password-validation) för mer information. Som standard utförs ingen validering och alla lösenord accepteras.

## Meddelanden

Inställningar för [`django.contrib.messages`](/sv/6.0/ref/contrib/messages/#module-django.contrib.messages).

### `MEDDELANDE_NIVÅ`

Standard: `meddelanden.INFO`

Anger den lägsta meddelandenivån som registreras av meddelanderamen. Se [meddelandenivåer](/sv/6.0/ref/contrib/messages/#message-level) för mer information.

> **Undvika cirkulär import**
>
> Om du åsidosätter `MESSAGE_LEVEL` i din inställningsfil och förlitar dig på någon av de inbyggda konstanterna, måste du importera konstantmodulen direkt för att undvika risken för cirkulär import, t.ex:
>
> ```
> from django.contrib.messages import constants as message_constants
>
> MESSAGE_LEVEL = message_constants.DEBUG
> ```
>
> Om så önskas kan du ange de numeriska värdena för konstanterna direkt enligt värdena i ovanstående [constants table](/sv/6.0/ref/contrib/messages/#message-level-constants).

### `MEDDELANDE_LAGRING`

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](/sv/6.0/ref/contrib/messages/#message-storage-backends) för mer information.

De backends som använder cookies – [`CookieStorage`](/sv/6.0/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) och [`FallbackStorage`](/sv/6.0/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage) – använder värdet av [`SESSION_COOKIE_DOMAIN`](#std-setting-SESSION_COOKIE_DOMAIN), [`SESSION_COOKIE_SECURE`](#std-setting-SESSION_COOKIE_SECURE) och [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) när de ställer in sina cookies.

### `MEDDELANDEN_TAGGAR`

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](/sv/6.0/ref/contrib/messages/#message-displaying) ovan för mer information.

> **Undvika cirkulär import**
>
> Om du åsidosätter `MESSAGE_TAGS` i din inställningsfil och förlitar dig på någon av de inbyggda konstanterna, måste du importera `constants`-modulen direkt för att undvika risken för cirkulär import, t.ex:
>
> ```
> from django.contrib.messages import constants as message_constants
>
> MESSAGE_TAGS = {message_constants.INFO: ""}
> ```
>
> Om så önskas kan du ange de numeriska värdena för konstanterna direkt enligt värdena i ovanstående [constants table](/sv/6.0/ref/contrib/messages/#message-level-constants).

## Sessioner

Inställningar för [`django.contrib.sessions`](/sv/6.0/topics/http/sessions/#module-django.contrib.sessions).

### `SESSION_CACHE_ALIAS`

Standard: `'default'`

Om du använder [cache-baserad sessionslagring](/sv/6.0/topics/http/sessions/#cached-sessions-backend), väljer du här vilken cache som ska användas.

### `SESSION_COOKIE_AGE`

Standard: `1209600` (2 veckor, i sekunder)

Ålder för sessionscookies, i sekunder.

### `SESSION_COOKIE_DOMÄN`

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`](#std-setting-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`](/sv/6.0/ref/contrib/messages/#module-django.contrib.messages).

### `SESSION_COOKIE_HTTPONLY`

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](https://owasp.org/www-community/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**](https://datatracker.ietf.org/doc/html/rfc6265.html#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_NAMN`

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_PATH`

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_SAMESITE`

Standard: `'Lax'`

Värdet på flaggan [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) 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.

> **Note**
>
> Moderna webbläsare har en säkrare standardpolicy för flaggan ”Samma webbplats” och antar ”Lax” för cookies utan en uttrycklig värdeinställning.

### `SESSION_COOKIE_SECURE`

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_ENGINE`

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](/sv/6.0/topics/http/sessions/#configuring-sessions) för mer information.

### `SESSION_EXPIRE_AT_BROWSER_CLOSE`

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](/sv/6.0/topics/http/sessions/#browser-length-vs-persistent-sessions).

### `SESSION_FILE_PATH`

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_REQUEST`

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_SERIALIZER`

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](/sv/6.0/topics/http/sessions/#session-serialization) för mer information.

## Webbplatser

Inställningar för [`django.contrib.sites`](/sv/6.0/ref/contrib/sites/#module-django.contrib.sites).

### `SITE_ID`

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.

## Statiska filer

Inställningar för [`django.contrib.staticfiles`](/sv/6.0/ref/contrib/staticfiles/#module-django.contrib.staticfiles).

### `STATISK_ROOT`

Standard: `None`

Den absoluta sökvägen till den katalog där [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) ska samla in statiska filer för distribution.

Exempel: `"/var/www/example.com/static/"`

Om contrib-appen [staticfiles](/sv/6.0/ref/contrib/staticfiles/) är aktiverad (som i standardprojektmallen) kommer kommandot [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) att samla in statiska filer till den här katalogen. Se guiden [hantering av statiska filer](/sv/6.0/howto/static-files/) för mer information om användning.

> **Warning**
>
> Detta bör vara en ursprungligen tom destinationskatalog för att samla dina statiska filer från deras permanenta platser till en katalog för att underlätta distributionen; det är **inte** en plats att lagra dina statiska filer permanent. Du bör göra det i kataloger som kommer att hittas av [staticfiles](/sv/6.0/ref/contrib/staticfiles/) [`finders`](#std-setting-STATICFILES_FINDERS), som som standard är `'static/'` appunderkataloger och alla kataloger som du inkluderar i [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS)).

### `STATIC_URL`

Standard: `None`

URL som ska användas vid hänvisning till statiska filer som finns i [`STATIC_ROOT`](#std-setting-STATIC_ROOT).

Exempel: `"static/"` eller `"https://static.example.com/"`

Om inte `None`, kommer detta att användas som basväg för [asset definitions](/sv/6.0/topics/forms/media/#form-asset-paths) (klassen `Media`) och [staticfiles app](/sv/6.0/ref/contrib/staticfiles/).

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](/sv/6.0/howto/static-files/#serving-static-files-in-development) och du kommer definitivt att behöva göra det [under produktion](/sv/6.0/howto/static-files/deployment/).

> **Note**
>
> Om [`STATIC_URL`](#std-setting-STATIC_URL) är en relativ sökväg kommer den att föregås av det servertillhandahållna värdet för `SCRIPT_NAME` (eller `/` om det inte är angivet). Detta gör det enklare att servera en Django-applikation i en underväg utan att lägga till en extra konfiguration i inställningarna.

### `STATICFILES_DIRS`

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`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) eller [`findstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-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"`).

#### Prefix (valfritt)

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 = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]
```

Om du till exempel antar att du har [`STATIC_URL`](#std-setting-STATIC_URL) inställd på `'static/'`, skulle kommandot [`collectstatic`](/sv/6.0/ref/contrib/staticfiles/#django-admin-collectstatic) samla in ”stats”-filerna i underkatalogen `'downloads'` i [`STATIC_ROOT`](#std-setting-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:

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

### `STATISKA FILER_FINDERS`

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`](#std-setting-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`](#std-setting-STATICFILES_FINDERS) kommer den att leta efter statiska filer i standardfillagringen som definieras av nyckeln `default` i inställningen `` STORAGES` ``.

> **Note**
>
> När du använder sökfunktionen `AppDirectoriesFinder` ska du se till att dina appar kan hittas av statiska filer genom att lägga till appen i inställningen [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) på din webbplats.

Statiska filsökare betraktas för närvarande som ett privat gränssnitt, och detta gränssnitt är därför odokumenterat.

## Aktuellt index för kärninställningar

### Cache

- [`CACHES`](#std-setting-CACHES)
- [`CACHE_MIDDLEWARE_ALIAS`](#std-setting-CACHE_MIDDLEWARE_ALIAS)
- [`CACHE_MIDDLEWARE_KEY_PREFIX`](#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX)
- [`CACHE_MIDDLEWARE_SECONDS`](#std-setting-CACHE_MIDDLEWARE_SECONDS)

### Databas

- `DATABASER`
- [`DATABASE_ROUTERS`](#std-setting-DATABASE_ROUTERS)
- [`DEFAULT_INDEX_TABLESPACE`](#std-setting-DEFAULT_INDEX_TABLESPACE)
- [`DEFAULT_TABLESPACE`](#std-setting-DEFAULT_TABLESPACE)

### Felsökning

- [`DEBUG`](#std-setting-DEBUG)
- [`DEBUG_PROPAGATE_EXCEPTIONS`](#std-setting-DEBUG_PROPAGATE_EXCEPTIONS)

### E-postadress

- [`ADMINS`](#std-setting-ADMINS)
- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL)
- [`EMAIL_BACKEND`](#std-setting-EMAIL_BACKEND)
- [`EMAIL_FILE_PATH`](#std-setting-EMAIL_FILE_PATH)
- [`EMAIL_HOST`](#std-setting-EMAIL_HOST)
- [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD)
- [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER)
- [`EMAIL_PORT`](#std-setting-EMAIL_PORT)
- [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE)
- [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE)
- [`EMAIL_SUBJECT_PREFIX`](#std-setting-EMAIL_SUBJECT_PREFIX)
- [`EMAIL_TIMEOUT`](#std-setting-EMAIL_TIMEOUT)
- [`EMAIL_USE_LOCALTIME`](#std-setting-EMAIL_USE_LOCALTIME)
- [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL)
- [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS)
- [`MANAGERS`](#std-setting-MANAGERS)
- [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL)

### Felrapportering

- [`DEFAULT_EXCEPTION_REPORTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER)
- [`DEFAULT_EXCEPTION_REPORTER_FILTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER)
- [`IGNORABLE_404_URLS`](#std-setting-IGNORABLE_404_URLS)
- [`MANAGERS`](#std-setting-MANAGERS)
- [`SILENCED_SYSTEM_CHECKS`](#std-setting-SILENCED_SYSTEM_CHECKS)

### Filuppladdningar

- [`FILE_UPLOAD_HANDLERS`](#std-setting-FILE_UPLOAD_HANDLERS)
- [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE)
- [`FILE_UPLOAD_DIRECTORY_PERMISSIONS`](#std-setting-FILE_UPLOAD_DIRECTORY_PERMISSIONS)
- [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS)
- [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR)
- [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT)
- [`MEDIA_URL`](#std-setting-MEDIA_URL)
- [`STORAGES`](#std-setting-STORAGES)

### Formulär

- [`FORM_RENDERER`](#std-setting-FORM_RENDERER)

### Globalisering (`i18n`/l10n\`)

#### Internationalisering (`i18n`)

- `FÖRSTA_DAGEN_I_VECKAN`
- [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH)
- [`LANGUAGE_COOKIE_AGE`](#std-setting-LANGUAGE_COOKIE_AGE)
- [`LANGUAGE_COOKIE_DOMAIN`](#std-setting-LANGUAGE_COOKIE_DOMAIN)
- [`LANGUAGE_COOKIE_HTTPONLY`](#std-setting-LANGUAGE_COOKIE_HTTPONLY)
- [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME)
- [`LANGUAGE_COOKIE_PATH`](#std-setting-LANGUAGE_COOKIE_PATH)
- [`LANGUAGE_COOKIE_SAMESITE`](#std-setting-LANGUAGE_COOKIE_SAMESITE)
- [`LANGUAGE_COOKIE_SECURE`](#std-setting-LANGUAGE_COOKIE_SECURE)
- [`LANGUAGES`](#std-setting-LANGUAGES)
- [`LANGUAGES_BIDI`](#std-setting-LANGUAGES_BIDI)
- [`LOCALE_PATHS`](#std-setting-LOCALE_PATHS)
- [`TIME_ZONE`](#std-setting-TIME_ZONE)
- [`USE_I18N`](#std-setting-USE_I18N)
- [`USE_TZ`](#std-setting-USE_TZ)

#### Lokalisering (`l10n`)

- [`DATE_FORMAT`](#std-setting-DATE_FORMAT)
- [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS)
- [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT)
- [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS)
- [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR)
- [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE)
- [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT)
- [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING)
- [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT)
- [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT)
- [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR)
- [`TIME_FORMAT`](#std-setting-TIME_FORMAT)
- [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS)
- [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR)
- [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT)

### HTTP

- [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE)
- [`DATA_UPLOAD_MAX_NUMBER_FIELDS`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FIELDS)
- [`DATA_UPLOAD_MAX_NUMBER_FILES`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FILES)
- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`DISALLOWED_USER_AGENTS`](#std-setting-DISALLOWED_USER_AGENTS)
- [`FORCE_SCRIPT_NAME`](#std-setting-FORCE_SCRIPT_NAME)
- [`INTERNAL_IPS`](#std-setting-INTERNAL_IPS)
- [`MIDDLEWARE`](#std-setting-MIDDLEWARE)
- Säkerhet

  - [`SECURE_CONTENT_TYPE_NOSNIFF`](#std-setting-SECURE_CONTENT_TYPE_NOSNIFF)
  - [`SECURE_CROSS_ORIGIN_OPENER_POLICY`](#std-setting-SECURE_CROSS_ORIGIN_OPENER_POLICY)
  - [`SECURE_CSP`](#std-setting-SECURE_CSP)
  - [`SECURE_CSP_REPORT_ONLY`](#std-setting-SECURE_CSP_REPORT_ONLY)
  - [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS)
  - [`SECURE_HSTS_PRELOAD`](#std-setting-SECURE_HSTS_PRELOAD)
  - [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS)
  - [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER)
  - [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT)
  - [`SECURE_REFERRER_POLICY`](#std-setting-SECURE_REFERRER_POLICY)
  - [`SECURE_SSL_HOST`](#std-setting-SECURE_SSL_HOST)
  - [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT)
- [`SIGNED_COOKIE_LEGACY_SALT_FALLBACK`](#std-setting-SIGNED_COOKIE_LEGACY_SALT_FALLBACK)
- [`SIGNING_BACKEND`](#std-setting-SIGNING_BACKEND)
- [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST)
- [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT)
- [`WSGI_APPLICATION`](#std-setting-WSGI_APPLICATION)

### Loggning

- [`LOGGING`](#std-setting-LOGGING)
- [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG)

### Modeller

- [`ABSOLUTE_URL_OVERRIDES`](#std-setting-ABSOLUTE_URL_OVERRIDES)
- [`FIXTURE_DIRS`](#std-setting-FIXTURE_DIRS)
- [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS)

### Säkerhet

- Skydd mot Cross Site Request Forgery

  - [`CSRF_COOKIE_DOMAIN`](#std-setting-CSRF_COOKIE_DOMAIN)
  - [`CSRF_COOKIE_NAME`](#std-setting-CSRF_COOKIE_NAME)
  - [`CSRF_COOKIE_PATH`](#std-setting-CSRF_COOKIE_PATH)
  - [`CSRF_COOKIE_SAMESITE`](#std-setting-CSRF_COOKIE_SAMESITE)
  - [`CSRF_COOKIE_SECURE`](#std-setting-CSRF_COOKIE_SECURE)
  - [`CSRF_FAILURE_VIEW`](#std-setting-CSRF_FAILURE_VIEW)
  - [`CSRF_HEADER_NAME`](#std-setting-CSRF_HEADER_NAME)
  - [`CSRF_TRUSTED_ORIGINS`](#std-setting-CSRF_TRUSTED_ORIGINS)
  - [`CSRF_USE_SESSIONS`](#std-setting-CSRF_USE_SESSIONS)
- [`SECRET_KEY`](#std-setting-SECRET_KEY)
- [`SECRET_KEY_FALLBACKS`](#std-setting-SECRET_KEY_FALLBACKS)
- [`URLIZE_ASSUME_HTTPS`](#std-setting-URLIZE_ASSUME_HTTPS)
- [`X_FRAME_OPTIONS`](#std-setting-X_FRAME_OPTIONS)

### Serialisering

- [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET)
- [`SERIALIZATION_MODULES`](#std-setting-SERIALIZATION_MODULES)

### Mallar

- [`TEMPLATES`](#std-setting-TEMPLATES)

### Testar

- Databas: [`TEST`](#std-setting-DATABASE-TEST)
- [`TEST_NON_SERIALIZED_APPS`](#std-setting-TEST_NON_SERIALIZED_APPS)
- [`TEST_RUNNER`](#std-setting-TEST_RUNNER)

### URL:er

- [`APPEND_SLASH`](#std-setting-APPEND_SLASH)
- [`PREPEND_WWW`](#std-setting-PREPEND_WWW)
- [`ROOT_URLCONF`](#std-setting-ROOT_URLCONF)