djangodocs

Django 5.2
Svenska
Documentation contents

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:

    Code
    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

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.

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.

Du kan tillämpa GZip-komprimering på enskilda vyer med hjälp av gzip_page()-dekoratorn.

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.

Du kan hantera villkorliga GET-operationer med enskilda vyer med hjälp av conditional_page()-dekoratorn.

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

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.

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.

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.

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.

Samma ursprung

Anvisar webbläsaren att skicka en fullständig URL, men endast för länkar med samma ursprung. Ingen referrer kommer att skickas för länkar med korsande ursprung.

strict-origin

Instruerar webbläsaren att endast skicka ursprunget, inte hela URL:en, och att inte skicka någon referent när en protokollnedgradering inträffar.

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

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.

För att förhindra webbläsaren från att gissa innehållstypen och tvinga den att alltid använda den typ som anges i Content-Type-huvudet, kan du skicka `X-Content-Type-Options: nosniff`__-huvudet. SecurityMiddleware kommer att göra detta för alla svar om inställningen SECURE_CONTENT_TYPE_NOSNIFF` är 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.

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.

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:

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

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

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

Du kan lägga till skydd mot Cross Site Request Forgery för enskilda vyer med hjälp av csrf_protect()-dekoratorn.

X-Frame-Options middleware

class XFrameOptionsMiddleware

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

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

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

  14. RedirectFallbackMiddleware

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

This page as Markdown JSON

Edit this page on GitHub Official version