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[source]¶

class FetchFromCacheMiddleware[source]¶

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[source]¶

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[source]¶

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

GZip mellanprogram¶

class GZipMiddleware[source]¶

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.

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

Villkorlig GET-mellanvara¶

class ConditionalGetMiddleware[source]¶

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[source]¶

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[source]¶

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[source]¶

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.

:inställning:`SECURE_CONTENT_TYPE_NOSNIFF`
:inställning:`SECURE_CROSS_ORIGIN_OPENER_POLICY`
:Inställning:`SECURE_HSTS_INCLUDE_SUBDOMAINS`
:inställning:`SECURE_HSTS_PRELOAD`
:inställning:`SECURE_HSTS_SECONDS`
:inställning:`SECURE_REDIRECT_EXEMPT`
:inställning:`SECURE_REFERRER_POLICY`
:Inställning:`SECURE_SSL_HOST`
:inställning:`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.
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.

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.

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.

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[source]¶

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

Middleware för webbplatsen¶

class CurrentSiteMiddleware[source]¶

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

Middleware för autentisering¶

class AuthenticationMiddleware[source]¶

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

class LoginRequiredMiddleware[source]¶

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()[source]¶: 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()[source]¶: 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.

New in Django 5.1.

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[source]¶

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[source]¶

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[source]¶

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[source]¶

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:

:klass:`~django.middleware.security.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.
UpdateCacheMiddleware

Före de som ändrar Vary-headern (SessionMiddleware, GZipMiddleware, LocaleMiddleware).
:klass:`~django.middleware.gzip.GZipMiddleware`

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

Efter UpdateCacheMiddleware: Ändrar rubriken Vary.
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.
:klass:`~django.middleware.http.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.
:klass:`~django.middleware.locale.LocaleMiddleware`

En av de översta, efter SessionMiddleware (använder sessionsdata) och UpdateCacheMiddleware (ändrar Vary header).
:klass:`~django.middleware.common.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.
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.
AuthenticationMiddleware

Efter SessionMiddleware: använder sessionslagring.
LoginRequiredMiddleware

New in Django 5.1.

Efter AuthenticationMiddleware: använder användarobjekt.
MessageMiddleware

Efter SessionMiddleware: kan använda sessionsbaserad lagring.
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.
FlatpageFallbackMiddleware

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

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

Middleware¶

Tillgänglig middleware¶

Middleware för cacheminne¶

”Vanlig” mellanprogramvara¶

GZip mellanprogram¶

Villkorlig GET-mellanvara¶

Middleware för lokal språkdräkt¶

Middleware för meddelanden¶

Middleware för säkerhet¶

HTTP Strict Transport Security¶

Policy för hänvisare¶

Policy för öppnare för flera ursprung¶

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

SSL-omdirigering¶

Mellanprogram för sessioner¶

Middleware för webbplatsen¶

Middleware för autentisering¶

Middleware för CSRF-skydd¶

`X-Frame-Options` middleware¶

Beställning av mellanprogramvara¶

Additional Information

Support Django!

Contents

Getting help

Download:

Middleware¶

Tillgänglig middleware¶

Middleware för cacheminne¶

”Vanlig” mellanprogramvara¶

GZip mellanprogram¶

Villkorlig GET-mellanvara¶

Middleware för lokal språkdräkt¶

Middleware för meddelanden¶

Middleware för säkerhet¶

HTTP Strict Transport Security¶

Policy för hänvisare¶

Policy för öppnare för flera ursprung¶

X-Content-Type-Options: nosniff¶

SSL-omdirigering¶

Mellanprogram för sessioner¶

Middleware för webbplatsen¶

Middleware för autentisering¶

Middleware för CSRF-skydd¶

X-Frame-Options middleware¶

Beställning av mellanprogramvara¶

Additional Information

Support Django!

Contents

Getting help

Download:

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

`X-Frame-Options` middleware¶