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.
\nAktivera 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.
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:
\nFö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\n\n\n@no_append_slash\ndef sensitive_fbv(request, *args, **kwargs):\n """View to be excluded from APPEND_SLASH."""\n return HttpResponse()\nStäller in rubriken Content-Length för svar som inte strömmas.
Skickar e-postmeddelanden om trasiga länkar till MANAGERS (se Hur man hanterar felrapportering).
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.
\nDen komprimerar INTE innehåll om något av följande är sant:
\nInnehå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.
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.
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.
\nAktiverar cookie- och sessionsbaserat meddelandestöd. Se meddelanden dokumentation.
\ndjango.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.
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).
\nSecurityMiddleware 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.
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.
\nVissa 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:
\nFull 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:
\nSamma 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änvisareAnvisar webbläsaren att inte skicka någon referent för länkar som klickas på denna webbplats.
\nInstruerar webbläsaren att skicka en fullständig URL som referent, men endast när ingen protokollnedgradering sker.
\nursprungInstruerar webbläsaren att endast skicka ursprunget, inte hela URL:en, som referent.
\nursprung-när-korsat-ursprungInstruerar 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.
\nSamma ursprungAnvisar 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.
\nstrict-originInstruerar webbläsaren att endast skicka ursprunget, inte hela URL:en, och att inte skicka någon referent när en protokollnedgradering inträffar.
\nInstruerar 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.
\nunsafe-urlInstruerar webbläsaren att alltid skicka den fullständiga URL:en som referent.
\nVissa 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 ursprungIsolerar 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.
\nIsolerar 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-noneTillå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: nosniffLink to this heading#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.
\nFö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.
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.
\nOm 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.
Aktiverar stöd för sessioner. Se session-dokumentation.
\nLägger till attributet site som representerar den aktuella webbplatsen till varje inkommande HttpRequest-objekt. Se sites dokumentation.
Lägger till attributet user, som representerar den inloggade användaren, till varje inkommande HttpRequest-objekt. Se Autenticering i webbförfrågningar.
Subklassa mellanvaran och åsidosätt följande attribut och metoder för att anpassa beteendet för oautentiserade begäranden.
\nStandardvärdet är "next".
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.
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 = [\n "...",\n "django.contrib.auth.middleware.AuthenticationMiddleware",\n "django.contrib.auth.middleware.LoginRequiredMiddleware",\n "...",\n]\nGö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\n\n\n@login_not_required\ndef contact_us(request): ...\nAnpassa 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\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import View\n\n\n@login_required(login_url="/books/login/", redirect_field_name="redirect_to")\ndef book_dashboard(request): ...\n\n\n@method_decorator(\n login_required(login_url="/books/login/", redirect_field_name="redirect_to"),\n name="dispatch",\n)\nclass BookMetrics(View):\n pass\nMiddleware 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.
\nMiddleware 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.
\nLä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.
\nDu kan lägga till skydd mot Cross Site Request Forgery för enskilda vyer med hjälp av csrf_protect()-dekoratorn.
X-Frame-Options middlewareLink to this heading#Här är några tips om ordningen för olika Django middleware-klasser:
\nDen 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.
\nFöre de som ändrar Vary-headern (SessionMiddleware, GZipMiddleware, LocaleMiddleware).
Före alla mellanprogram som kan ändra eller använda svarskroppen.
\nEfter UpdateCacheMiddleware: Ändrar rubriken Vary.
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.
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.
En av de översta, efter SessionMiddleware (använder sessionsdata) och UpdateCacheMiddleware (ändrar Vary header).
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.
Innan någon vy middleware som förutsätter att CSRF-attacker har hanterats.
\nFö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.
Efter SessionMiddleware: använder sessionslagring.
Efter AuthenticationMiddleware: använder användarobjekt.
Efter SessionMiddleware: kan använda sessionsbaserad lagring.
Efter alla mellanprogram som ändrar rubriken Vary: den rubriken används för att välja ett värde för cachens hash-nyckel.
Borde ligga längst ner eftersom det är en sista utväg för mellanprogram.
\nBorde ligga längst ner eftersom det är en sista utväg för mellanprogram.
\n