# Django 5.2.8 documentation

# Middleware

Detta dokument förklarar alla middleware-komponenter som medföljer Django. För information om hur du använder dem och hur du skriver din egen middleware, se middleware usage guide.

## Tillgänglig middleware

### Middleware för cacheminne

class UpdateCacheMiddleware

class FetchFromCacheMiddleware

Aktivera den webbplatsomfattande cacheminnet. Om dessa är aktiverade kommer varje Django-driven sida att cachas så länge som inställningen `CACHE_MIDDLEWARE_SECONDS` definierar. Se cache-dokumentation.

### ”Vanlig” mellanprogramvara

class CommonMiddleware
  response_redirect_class

    Standardvärde för `HttpResponsePermanentRedirect`. Underklass `CommonMiddleware` och åsidosätt attributet för att anpassa de omdirigeringar som utfärdas av mellanvaran.

Lägger till några bekvämligheter för perfektionister:

- Förbjuder åtkomst till användaragenter i inställningen `DISALLOWED_USER_AGENTS`, som bör vara en lista över kompilerade objekt med reguljära uttryck.

- Utför URL-omskrivning baserat på inställningarna `APPEND_SLASH` och `PREPEND_WWW`.

  Om `APPEND_SLASH` är `True` och den ursprungliga URL:en inte slutar med ett snedstreck, och den inte finns i URLconf, så bildas en ny URL genom att lägga till ett snedstreck i slutet. Om denna nya URL finns i URLconf, omdirigerar Django begäran till denna nya URL. I annat fall behandlas den ursprungliga URL:en som vanligt.

  Till exempel: kommer `foo.com/bar` att omdirigeras till `foo.com/bar/` om du inte har ett giltigt URL-mönster för `foo.com/bar` men har ett giltigt mönster för `foo.com/bar/`.

  Om `PREPEND_WWW` är `True` kommer webbadresser som saknar ett inledande ”www.” att omdirigeras till samma webbadress med ett inledande ”www.”

  Båda dessa alternativ är avsedda att normalisera webbadresser. Filosofin är att varje URL ska finnas på en och endast en plats. Tekniskt sett skiljer sig en URL `foo.com/bar` från `foo.com/bar/` - en sökmotors indexerare skulle behandla dem som separata URL:er - så det är bästa praxis att normalisera URL:er.

  Om det behövs kan enskilda vyer uteslutas från `APPEND_SLASH`-beteendet med hjälp av `no_append_slash()` decorator:

      from django.views.decorators.common import no_append_slash

      @no_append_slash
      def sensitive_fbv(request, *args, **kwargs):
          """View to be excluded from APPEND_SLASH."""
          return HttpResponse()

- Ställer in rubriken `Content-Length` för svar som inte strömmas.

class BrokenLinkEmailsMiddleware

- Skickar e-postmeddelanden om trasiga länkar till `MANAGERS` (se Hur man hanterar felrapportering).

### GZip mellanprogram

class GZipMiddleware
  max_random_bytes

    Standardvärde är 100. Underklassa `GZipMiddleware` och åsidosätt attributet för att ändra det maximala antalet slumpmässiga byte som ingår i komprimerade svar.

Observera

Säkerhetsforskare avslöjade att när komprimeringstekniker (inklusive `GZipMiddleware`) används på en webbplats kan webbplatsen utsättas för ett antal möjliga attacker.

För att mildra attacker implementerar Django en teknik som kallas Heal The Breach (HTB). Den lägger till upp till 100 byte (se `max_random_bytes`) slumpmässiga byte till varje svar för att göra attackerna mindre effektiva.

För mer information, se ”Breach paper (PDF)`_, ”breachattack.com`_ och ”Heal The Breach (HTB) paper`_.

`django.middleware.gzip.GZipMiddleware` komprimerar innehåll för webbläsare som förstår GZip-komprimering (alla moderna webbläsare).

Denna middleware bör placeras före alla andra middleware som behöver läsa eller skriva svarskroppen så att komprimeringen sker efteråt.

Den komprimerar INTE innehåll om något av följande är sant:

- Innehållet är mindre än 200 byte långt.

- Svaret har redan ställt in rubriken `Content-Encoding`.

- Begäran (webbläsaren) har inte skickat ett `Accept-Encoding`-huvud som innehåller `gzip`.

Om svaret har en `ETag` header, görs ETag svag för att följa RFC 9110 Section 8.8.1.

You can apply GZip compression to individual views using the `gzip_page()` decorator.

### Villkorlig GET-mellanvara

class ConditionalGetMiddleware

Hanterar villkorliga GET-operationer. Om svaret inte har någon `ETag`-rubrik lägger mellanvaran till en vid behov. Om svaret har en `ETag` eller `Last-Modified` header, och begäran har `If-None-Match` eller `If-Modified-Since`, ersätts svaret av en `HttpResponseNotModified`.

You can handle conditional GET operations with individual views using the `conditional_page()` decorator.

### Middleware för lokal språkdräkt

class LocaleMiddleware
  response_redirect_class

    Standardvärde för `HttpResponseRedirect`. Underklassa `LocaleMiddleware` och åsidosätt attributet för att anpassa de omdirigeringar som utfärdas av mellanvaran.

Möjliggör språkval baserat på data från begäran. Det anpassar innehållet för varje användare. Se dokumentation om internationalisering.

### Middleware för meddelanden

class MessageMiddleware

Aktiverar cookie- och sessionsbaserat meddelandestöd. Se meddelanden dokumentation.

### Middleware för säkerhet

Varning

Om din distributionssituation tillåter det är det vanligtvis en bra idé att låta din front-end webbserver utföra den funktionalitet som tillhandahålls av `SecurityMiddleware`. På så sätt, om det finns förfrågningar som inte serveras av Django (t.ex. statiska media eller användaruppladdade filer), kommer de att ha samma skydd som förfrågningar till din Django-applikation.

class SecurityMiddleware

`django.middleware.security.SecurityMiddleware` ger flera säkerhetsförbättringar till request/response-cykeln. Var och en kan aktiveras eller inaktiveras oberoende av varandra med en inställning.

- `SECURE_CONTENT_TYPE_NOSNIFF`

- `SECURE_CROSS_ORIGIN_OPENER_POLICY`

- `SECURE_HSTS_INCLUDE_SUBDOMAINS`

- `SECURE_HSTS_PRELOAD`

- `SECURE_HSTS_SECONDS`

- `SECURE_REDIRECT_EXEMPT`

- `SECURE_REFERRER_POLICY`

- `SECURE_SSL_HOST`

- `SECURE_SSL_REDIRECT`

#### HTTP Strict Transport Security

För webbplatser som endast bör nås via HTTPS kan du instruera moderna webbläsare att vägra ansluta till ditt domännamn via en osäker anslutning (under en viss tidsperiod) genom att ställa in rubriken ”Strict-Transport-Security”. Detta minskar din exponering för vissa SSL-strippande MITM-attacker (man-in-the-middle).

`SecurityMiddleware` kommer att ställa in detta huvud åt dig på alla HTTPS-svar om du ställer in `SECURE_HSTS_SECONDS` till ett heltal som inte är noll.

När du aktiverar HSTS är det en bra idé att först använda ett litet värde för testning, t.ex. `SECURE_HSTS_SECONDS = 3600` för en timme. Varje gång en webbläsare ser HSTS-rubriken från din webbplats kommer den att vägra att kommunicera på ett icke-säkert sätt (med HTTP) med din domän under den angivna tidsperioden. När du har bekräftat att alla tillgångar serveras säkert på din webbplats (dvs. att HSTS inte förstörde något) är det en bra idé att öka detta värde så att besökare som kommer sällan skyddas (31536000 sekunder, dvs. 1 år, är vanligt).

Om du dessutom anger inställningen `SECURE_HSTS_INCLUDE_SUBDOMAINS` till `True`, kommer `SecurityMiddleware` att lägga till direktivet `includeSubDomains` i `Strict-Transport-Security`-headern. Detta rekommenderas (förutsatt att alla underdomäner serveras uteslutande med HTTPS), annars kan din webbplats fortfarande vara sårbar via en osäker anslutning till en underdomän.

Om du vill lägga till din webbplats i listan över förinlästa sidor i webbläsaren ska du ställa in `SECURE_HSTS_PRELOAD` på `True`. Då läggs direktivet `preload` till i rubriken `Strict-Transport-Security`.

Varning

HSTS-policyn gäller för hela din domän, inte bara webbadressen till det svar som du anger rubriken för. Därför bör du bara använda den om hela din domän endast serveras via HTTPS.

Webbläsare som respekterar HSTS-rubriken kommer inte att tillåta användare att kringgå varningar och ansluta till en webbplats med ett utgånget, självsignerat eller på annat sätt ogiltigt SSL-certifikat. Om du använder HSTS ska du se till att dina certifikat är i gott skick och att de förblir det!

Observera

Om du är placerad bakom en lastbalanserare eller omvänd proxyserver och rubriken `Strict-Transport-Security` inte läggs till i dina svar, kan det bero på att Django inte inser att det är på en säker anslutning; du kan behöva ställa in `SECURE_PROXY_SSL_HEADER`-inställningen.

#### Policy för hänvisare

Webbläsare använder Referer-headern som ett sätt att skicka information till en webbplats om hur användarna kom dit. När en användare klickar på en länk skickar webbläsaren hela webbadressen till den länkande sidan som referent. Detta kan vara användbart för vissa ändamål - som att ta reda på vem som länkar till din webbplats - men det kan också orsaka integritetsproblem genom att informera en webbplats om att en användare har besökt en annan webbplats.

Vissa webbläsare har möjlighet att acceptera tips om huruvida de ska skicka HTTP-rubriken ”Referer” när en användare klickar på en länk; detta tips tillhandahålls via rubriken ”Referrer-Policy”. Detta huvud kan föreslå något av tre beteenden för webbläsare:

- Full URL: skicka hela URL:en i rubriken `Referer`. Om användaren t.ex. besöker `https://example.com/page.html`, skulle `Referer`-headern innehålla `"https://example.com/page.html"`.

- Endast ursprung: skicka endast ”ursprunget” i referensen. Ursprunget består av schema, värd och (valfritt) portnummer. Om användaren t.ex. besöker `https://example.com/page.html`, skulle ursprunget vara `https://example.com/`.

- Ingen referrer: skicka inte någon `Referer` header alls.

Det finns två typer av tillstånd som denna rubrik kan tala om för en webbläsare att se upp med:

- Samma ursprung kontra korsande ursprung: en länk från `https://example.com/1.html` till `https://example.com/2.html` är samma ursprung. En länk från `https://example.com/page.html` till `https://not.example.com/page.html` är cross-origin.

- Protokollnedgradering: en nedgradering sker om sidan som innehåller länken serveras via HTTPS, men sidan som länkas till inte serveras via HTTPS.

Varning

När din webbplats serveras via HTTPS kräver Djangos CSRF-skyddssystem att rubriken `Referer` finns, så att helt inaktivera rubriken `Referer` kommer att störa CSRF-skyddet. För att få de flesta fördelarna med att inaktivera `Referer`-rubriker och samtidigt behålla CSRF-skyddet, överväg att endast aktivera referenser med samma ursprung.

`SecurityMiddleware` kan ställa in rubriken `Referrer-Policy` åt dig, baserat på inställningen `SECURE_REFERRER_POLICY` (notera stavning: webbläsare skickar en rubrik `Referer` när en användare klickar på en länk, men rubriken som instruerar en webbläsare om att göra det stavas `Referrer-Policy`). De giltiga värdena för denna inställning är:

`Ingen hänvisare`

  Anvisar webbläsaren att inte skicka någon referent för länkar som klickas på denna webbplats.

”Ingen hänvisning vid nedgradering” (no-referrer-when-downgrade)

  Instruerar webbläsaren att skicka en fullständig URL som referent, men endast när ingen protokollnedgradering sker.

`ursprung`

  Instruerar webbläsaren att endast skicka ursprunget, inte hela URL:en, som referent.

`ursprung-när-korsat-ursprung`

  Instruerar webbläsaren att skicka hela URL:en som referent för länkar med samma ursprung, och endast ursprunget för länkar med olika ursprung.

`same-origin` Instructs the browser to send a full URL, but only for same-origin links. No referrer will be sent for cross-origin links.

`strict-origin` Instructs the browser to send only the origin, not the full URL, and to send no referrer when a protocol downgrade occurs.

”begränsa ursprunget när det korsas

  Instruerar webbläsaren att skicka hela URL:en när länken är av samma ursprung och ingen protokollnedgradering sker; skicka endast ursprunget när länken är av korsande ursprung och ingen protokollnedgradering sker; och ingen referent när en protokollnedgradering sker.

`unsafe-url`

  Instruerar webbläsaren att alltid skicka den fullständiga URL:en som referent.

Okända policyvärden

Om ett policyvärde är ”okänt” för en användaragent är det möjligt att ange flera policyvärden för att tillhandahålla en reservlösning. Det senast angivna värdet som förstås har företräde. För att stödja detta kan en iterabel eller kommaseparerad sträng användas med `SECURE_REFERRER_POLICY`.

#### Policy för öppnare för flera ursprung

Vissa webbläsare har möjlighet att isolera toppnivåfönster från andra dokument genom att placera dem i en separat webbläsarkontextgrupp baserat på värdet i rubriken COOP (Cross-Origin Opener Policy). Om ett dokument som är isolerat på detta sätt öppnar ett popup-fönster med flera ursprung, kommer popup-fönstrets egenskap `window.opener` att vara `null`. Att isolera fönster med hjälp av COOP är ett djupförsvarsskydd mot cross-origin-attacker, särskilt sådana som Spectre som möjliggjorde exfiltrering av data som laddats in i en delad webbläsarkontext.

`SecurityMiddleware` kan ställa in rubriken `Cross-Origin-Opener-Policy` åt dig, baserat på inställningen `SECURE_CROSS_ORIGIN_OPENER_POLICY`. De giltiga värdena för denna inställning är:

`Samma ursprung`

  Isolerar bläddringskontexten uteslutande till dokument med samma ursprung. Dokument med olika ursprung läses inte in i samma bläddringskontext. Detta är standardalternativet och det säkraste alternativet.

samma-ursprung-tillåt-popups

  Isolerar bläddringskontexten till dokument med samma ursprung eller sådana som antingen inte anger COOP eller som väljer bort isolering genom att ange en COOP på `unsafe-none`.

`unsafe-none`

  Tillåter att dokumentet läggs till i öppnarens bläddringskontextgrupp om inte öppnaren själv har en COOP av `samme-origin` eller `samme-origin-allow-popups`.

#### `X-Content-Type-Options: nosniff`

Vissa webbläsare försöker gissa innehållstyperna för de tillgångar som de hämtar och åsidosätter rubriken `Content-Type`. Även om detta kan hjälpa till att visa webbplatser med felaktigt konfigurerade servrar, kan det också utgöra en säkerhetsrisk.

Om din webbplats serverar filer som laddats upp av användare kan en illvillig användare ladda upp en särskilt utformad fil som tolkas som HTML eller JavaScript av webbläsaren när du förväntade dig att det skulle vara något ofarligt.

To prevent the browser from guessing the content type and force it to always use the type provided in the `Content-Type` header, you can pass the `X-Content-Type-Options: nosniff`__ header. `SecurityMiddleware` will do this for all responses if the `SECURE_CONTENT_TYPE_NOSNIFF` setting is `True`.

Observera att i de flesta distributionssituationer där Django inte är inblandad i att servera filer som laddats upp av användaren, kommer den här inställningen inte att hjälpa dig. Till exempel:, om din `MEDIA_URL` serveras direkt av din front-end webbserver (nginx, Apache, etc.) så skulle du vilja ställa in den här rubriken där. Å andra sidan, om du använder Django för att göra något som att kräva auktorisering för att ladda ner filer och du inte kan ställa in rubriken med din webbserver, kommer den här inställningen att vara användbar.

#### SSL-omdirigering

Om din webbplats erbjuder både HTTP- och HTTPS-anslutningar kommer de flesta användare att hamna på en osäker anslutning som standard. För bästa säkerhet bör du omdirigera alla HTTP-anslutningar till HTTPS.

Om du sätter inställningen `SECURE_SSL_REDIRECT` till True kommer `SecurityMiddleware` att permanent (HTTP 301) omdirigera alla HTTP-anslutningar till HTTPS.

Observera

Av prestandaskäl är det att föredra att göra dessa omdirigeringar utanför Django, i en front-end lastbalanserare eller omvänd proxyserver som nginx. `SECURE_SSL_REDIRECT` är avsedd för distributionssituationer där detta inte är ett alternativ.

Om inställningen `SECURE_SSL_HOST` har ett värde kommer alla omdirigeringar att skickas till den värden i stället för till den ursprungligen begärda värden.

Om det finns några sidor på din webbplats som ska vara tillgängliga via HTTP och inte omdirigeras till HTTPS kan du lista reguljära uttryck för att matcha dessa webbadresser i inställningen `SECURE_REDIRECT_EXEMPT`.

Observera

Om du är placerad bakom en lastbalanserare eller omvänd proxyserver och Django inte verkar kunna avgöra när en begäran faktiskt redan är säker, kan du behöva ställa in `SECURE_PROXY_SSL_HEADER`.

### Mellanprogram för sessioner

class SessionMiddleware

Aktiverar stöd för sessioner. Se session-dokumentation.

### Middleware för webbplatsen

class CurrentSiteMiddleware

Lägger till attributet `site` som representerar den aktuella webbplatsen till varje inkommande `HttpRequest`-objekt. Se sites dokumentation.

### Middleware för autentisering

class AuthenticationMiddleware

Lägger till attributet `user`, som representerar den inloggade användaren, till varje inkommande `HttpRequest`-objekt. Se Autenticering i webbförfrågningar.

class LoginRequiredMiddleware

  Subklassa mellanvaran och åsidosätt följande attribut och metoder för att anpassa beteendet för oautentiserade begäranden.

  redirect_field_name

    Standardvärdet är `"next"`.

  get_login_url()

    Returnerar URL:en som oautentiserade förfrågningar kommer att omdirigeras till. Detta resultat är antingen `login_url` som ställts in på `login_required()` decorator (om inte `None`), eller `settings.LOGIN_URL`.

  get_redirect_field_name()

    Returnerar namnet på den frågeparameter som innehåller den URL som användaren ska omdirigeras till efter en lyckad inloggning. Detta resultat är antingen `redirect_field_name` som ställts in på `login_required()` decorator (om inte `None`), eller `redirect_field_name`. Om `None` returneras kommer ingen frågeparameter att läggas till.

Omdirigerar alla oautentiserade förfrågningar till en inloggningssida, utom för vyer som utesluts med `login_not_required()`. Inloggningssidan är som standard `settings.LOGIN_URL`, men kan anpassas.

Aktivera denna middleware genom att lägga till den i inställningen `MIDDLEWARE` after `AuthenticationMiddleware`:

    MIDDLEWARE = [
        "...",
        "django.contrib.auth.middleware.AuthenticationMiddleware",
        "django.contrib.auth.middleware.LoginRequiredMiddleware",
        "...",
    ]

Gör en vy publik och tillåt oautentiserade förfrågningar med `login_not_required()`. Till exempel:

    from django.contrib.auth.decorators import login_not_required

    @login_not_required
    def contact_us(request): ...

Anpassa inloggningsadressen eller fältnamnet för autentiserade vyer med `login_required()` decorator för att ställa in `login_url` respektive `redirect_field_name`. Till exempel:

    from django.contrib.auth.decorators import login_required
    from django.utils.decorators import method_decorator
    from django.views.generic import View

    @login_required(login_url="/books/login/", redirect_field_name="redirect_to")
    def book_dashboard(request): ...

    @method_decorator(
        login_required(login_url="/books/login/", redirect_field_name="redirect_to"),
        name="dispatch",
    )
    class BookMetrics(View):
        pass

Se till att din inloggningsvy inte kräver inloggning.

För att förhindra oändliga omdirigeringar, se till att du har enabled unauthenticated requests till din inloggningsvy.

class RemoteUserMiddleware

Middleware för att använda autentisering som tillhandahålls av webbservern. Se Hur man autentiserar med hjälp av REMOTE_USER för användningsdetaljer.

class PersistentRemoteUserMiddleware

Middleware för att använda autentisering som tillhandahålls av webbservern när den endast är aktiverad på inloggningssidan. Se Använda REMOTE_USER endast på inloggningssidor för användningsdetaljer.

### Middleware för CSRF-skydd

class CsrfViewMiddleware

Lägger till skydd mot Cross Site Request Forgeries genom att lägga till dolda formulärfält i POST-formulär och kontrollera förfrågningar om rätt värde. Se Dokumentation om skydd mot Cross Site Request Forgery.

You can add Cross Site Request Forgery protection to individual views using the `csrf_protect()` decorator.

### `X-Frame-Options` middleware

class XFrameOptionsMiddleware

Enkel clickjacking-skydd via X-Frame-Options-huvudet.

### Content Security Policy middleware

class ContentSecurityPolicyMiddleware

New in Django 6.0.

Adds support for Content Security Policy (CSP), which helps mitigate risks such as Cross-Site Scripting (XSS) and data injection attacks by controlling the sources of content that can be loaded in the browser. See the Översikt documentation for details on configuring policies.

This middleware sets the following headers on the response depending on the available settings:

- `Content-Security-Policy`, based on `SECURE_CSP`.

- `Content-Security-Policy-Report-Only`, based on `SECURE_CSP_REPORT_ONLY`.

## Beställning av mellanprogramvara

Här är några tips om ordningen för olika Django middleware-klasser:

1. `SecurityMiddleware`

   Den bör ligga högst upp på listan om du ska aktivera SSL-omdirigeringen eftersom du då slipper köra igenom en massa andra onödiga mellanprogram.

2. `UpdateCacheMiddleware`

   Före de som ändrar `Vary`-headern (`SessionMiddleware`, `GZipMiddleware`, `LocaleMiddleware`).

3. `GZipMiddleware`

   Före alla mellanprogram som kan ändra eller använda svarskroppen.

   Efter `UpdateCacheMiddleware`: Ändrar rubriken `Vary`.

4. `SessionMiddleware`

   Innan någon middleware som kan ge upphov till ett undantag utlöser en felvy (t.ex. `PermissionDenied`) om du använder `CSRF_USE_SESSIONS`.

   Efter `UpdateCacheMiddleware`: Ändrar rubriken `Vary`.

5. `ConditionalGetMiddleware`

   Innan någon middleware som kan ändra svaret (den sätter `ETag`-headern).

   Efter `GZipMiddleware` så att den inte beräknar en `ETag` header på gzippat innehåll.

6. `LocaleMiddleware`

   En av de översta, efter `SessionMiddleware` (använder sessionsdata) och `UpdateCacheMiddleware` (ändrar `Vary` header).

7. `CommonMiddleware`

   Före alla mellanprogram som kan ändra svaret (det anger rubriken `Content-Length`). En middleware som visas före `CommonMiddleware` och ändrar svaret måste återställa `Content-Length`.

   Nära toppen: den omdirigerar när `APPEND_SLASH` eller `PREPEND_WWW` är inställda på `True`.

   Efter `SessionMiddleware` om du använder `CSRF_USE_SESSIONS`.

8. `CsrfViewMiddleware`

   Innan någon vy middleware som förutsätter att CSRF-attacker har hanterats.

   Före `RemoteUserMiddleware`, eller någon annan autentiseringsmellanvara som kan utföra en inloggning, och därmed rotera CSRF-token, innan den anropar vidare i mellanvarukedjan.

   Efter `SessionMiddleware` om du använder `CSRF_USE_SESSIONS`.

9. `AuthenticationMiddleware`

   Efter `SessionMiddleware`: använder sessionslagring.

10. `LoginRequiredMiddleware`

    Efter `AuthenticationMiddleware`: använder användarobjekt.

11. `MessageMiddleware`

    Efter `SessionMiddleware`: kan använda sessionsbaserad lagring.

12. `FetchFromCacheMiddleware`

    Efter alla mellanprogram som ändrar rubriken `Vary`: den rubriken används för att välja ett värde för cachens hash-nyckel.

13. `ContentSecurityPolicyMiddleware`

    Can be placed near the bottom, but ensure any middleware that accesses csp_nonce is positioned after it, so the nonce is properly included in the response header.

14. `FlatpageFallbackMiddleware`

    Borde ligga längst ner eftersom det är en sista utväg för mellanprogram.

15. `RedirectFallbackMiddleware`

    Borde ligga längst ner eftersom det är en sista utväg för mellanprogram.