Django-Middleware

Django-Middleware ist ein Hook zum Ändern von Django-Anfrage- oder -Antwortobjekten; sie kann als Verarbeitungsschritt zwischen der Behandlung von HttpRequest und HttpResponse verstanden werden.

Während des Prozesses von der Anfrage zur Antwort im Browser muss Django diese durch viele Middleware-Komponenten verarbeiten, wie in der folgenden Abbildung gezeigt:

Zweck der Django-Middleware:

  • Die Anfrage ändern, d. h. das an die View übergebene HttpRequest-Objekt.
  • Die Antwort ändern, d. h. das von der View zurückgegebene HttpResponse-Objekt.

Middleware-Komponenten werden in der MIDDLEWARE-Optionsliste in der Datei settings.py konfiguriert.

Jede String-Option in der Konfiguration ist eine Klasse, d. h. eine Middleware.

Djangos Standard-Middleware-Konfiguration:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Benutzerdefinierte Middleware

Middleware kann vier Methoden definieren, nämlich:

process_request(self,request)
process_view(self, request, view_func, view_args, view_kwargs)
process_exception(self, request, exception)
process_response(self, request, response)

Schritte zum Anpassen der Middleware:

Erstellen Sie eine neue py-Datei im App-Verzeichnis mit einem benutzerdefinierten Namen und importieren Sie MiddlewareMixin in dieser py-Datei:

from django.utils.deprecation import MiddlewareMixin

Eine benutzerdefinierte Middleware-Klasse muss von der Elternklasse MiddlewareMixin erben:

class MD1(MiddlewareMixin): 
    pass
Registrieren Sie die benutzerdefinierte Middleware-Klasse in MIDDLEWARE in settings.py:
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
   
    'app01.middlewares.MD1',
]

Methoden benutzerdefinierter Middleware-Klassen

Die Methoden einer benutzerdefinierten Middleware-Klasse umfassen: process_request und process_response.

process_request-Methode

Die process_request-Methode hat einen Parameter, request, der mit dem request in der View-Funktion identisch ist.

Der Rückgabewert der process_request-Methode kann entweder None oder ein HttpResponse-Objekt sein.

  • Wenn der Rückgabewert None ist, wird der normale Ablauf fortgesetzt und der Request wird zur Verarbeitung an die nächste Middleware übergeben.
  • Wenn der Rückgabewert ein HttpResponse-Objekt ist, führt Django weder die Methoden vor der nachfolgenden View-Funktion noch die View-Funktion selbst aus. Stattdessen führt es ab dieser Middleware die Middleware in umgekehrter Reihenfolge aus und führt nur die Methoden aus, die nach der View-Funktion ausgeführt werden.

Die process_request-Methode wird vor der View-Funktion ausgeführt.

Wenn mehrere Middlewares konfiguriert sind, werden sie in der Reihenfolge gemäß der Registrierungsreihenfolge in MIDDLEWARE ausgeführt, d. h. dem Listenindexwert.

Der zwischen verschiedenen Middleware-Komponenten übergebene request-Parameter ist dasselbe request-Objekt.

Beispiel

from django.utils.deprecation import MiddlewareMixin

from django.shortcuts import render, HttpResponse

class MD1(MiddlewareMixin):
    def process_request(self, request):
       print("md1 process_request method.", id(request)) # Vor der View ausführen

process_response

Die Methode process_response hat zwei Parameter: einer ist request und der andere ist response. request ist das Request-Objekt und response ist das von der View-Funktion zurückgegebene HttpResponse-Objekt. Diese Methode muss einen Rückgabewert haben, und dieser muss response sein.

Die Methode process_response wird nach der View-Funktion ausgeführt.

Wenn mehrere Middleware konfiguriert sind, werden sie gemäß der Registrierungsreihenfolge in MIDDLEWARE in umgekehrter Reihenfolge ausgeführt, d. h. dem Listenindexwert.

Beispiel

class MD1(MiddlewareMixin):
    def process_request(self, request):
        print("md1 process_request method.", id(request)) # Vor der View ausführen


    def process_response(self,request, response): :# Basierend auf request/response
        print("md1 process_response method!", id(request)) # Nach der View
        return response

Aus der folgenden Abbildung geht hervor, dass die Ausführung unter normalen Umständen dem grünen Weg folgt. AngenommenMiddleware 1Wenn es einen Rückgabewert gibt, folgt sie dem roten Weg, führt direkt die process_response-Methode dieser Klasse aus und kehrt zurück; die nachfolgenden anderen Middleware-Komponenten werden nicht ausgeführt.

process_view

Das Format der Methode process_view ist wie folgt:

process_view(request, view_func, view_args, view_kwargs)
Die Methode process_view hat vier Parameter:

  • request ist ein HttpRequest-Objekt.
  • view_func ist die View-Funktion, die Django verwenden wird.
  • view_args ist die Liste der Positionsargumente, die an die View übergeben werden.
  • view_kwargs ist das Wörterbuch der Schlüsselwortargumente, die an die View übergeben werden.

view_args und view_kwargs enthalten nicht den ersten View-Parameter (request).

Die Methode process_view wird vor der View-Funktion und nach der Methode process_request ausgeführt.

Der Rückgabewert kann None, view_func(request) oder ein HttpResponse-Objekt sein.

  • Wenn der Rückgabewert None ist, wird der normale Ablauf fortgesetzt und der Request wird zur Verarbeitung an die nächste Middleware übergeben.
  • Wenn der Rückgabewert ein HttpResponse-Objekt ist, führt Django weder die Methoden vor der nachfolgenden View-Funktion noch die View-Funktion selbst aus. Stattdessen führt es ab dieser Middleware die Middleware in umgekehrter Reihenfolge aus und führt nur die Methoden aus, die nach der View-Funktion ausgeführt werden.
  • c. Wenn der Rückgabewert view_func(request) ist, führt Django die Methoden vor nachfolgenden View-Funktionen nicht aus, sondern führt die View-Funktion im Voraus aus und führt dann die Methoden nach der View-Funktion in umgekehrter Reihenfolge aus.
  • Nachdem process_request der letzten Middleware das Routen-Mapping erreicht hat, kehrt es zum process_view der ersten Middleware zurück und geht dann nacheinander weiter nach unten, um die View-Funktion zu erreichen.

    Beispiel

    class MD1(MiddlewareMixin):
        def process_request(self, request):
            print("md1 process_request method.", id(request)) # Vor der View ausführen


        def process_response(self,request, response): :# Basierend auf request/response
            print("md1 process_response method!", id(request)) # Nach der View
            return response


        def process_view(self,request, view_func, view_args, view_kwargs):
            print(md1 process_view method!) # Vor der View ausführen; nacheinander ausführen
            #return view_func(request)

    process_exception

    Die Methode process_exception lautet wie folgt:

    process_exception(request, exception)

    Parameter description:

    • request ist ein HttpRequest-Objekt.
    • exception ist das Exception-Objekt, das durch eine Ausnahme in der View-Funktion erzeugt wird.

    Die Methode process_exception wird nur ausgeführt, wenn in der View-Funktion eine Ausnahme auftritt, und sie wird in umgekehrter Reihenfolge der Registrierung in settings ausgeführt.

    Wird nach der View-Funktion und vor der Methode process_response ausgeführt.

    Der Rückgabewert der Methode process_exception kann entweder None oder ein HttpResponse-Objekt sein.

    Wenn der Rückgabewert None ist, meldet die Seite einen Fehler mit Statuscode 500, und die View-Funktion wird nicht ausgeführt.

    Die Methode process_exception wird in umgekehrter Reihenfolge ausgeführt, und danach wird die Methode process_response in umgekehrter Reihenfolge ausgeführt.

    Wenn der Rückgabewert ein HttpResponse-Objekt ist, meldet die Seite keinen Fehler, und der Rückgabestatuscode ist 200.

    Die View-Funktion wird nicht ausgeführt, und die nachfolgenden process_exception-Methoden dieser Middleware werden ebenfalls nicht ausgeführt. Die Ausführung beginnt direkt bei der Methode process_response der letzten Middleware in umgekehrter Reihenfolge.

    Wenn die Methode process_view die View-Funktion zurückgibt und die View-Funktion vorab ausgeführt wird und die View-Funktion einen Fehler meldet, dann meldet die Seite unabhängig vom Rückgabewert der Methode process_exception einen Fehler, und weder die View-Funktion noch die Methode process_exception werden ausgeführt.

    Die Ausführung beginnt direkt in umgekehrter Reihenfolge bei der Methode process_response der letzten Middleware:

    Beispiel

    class MD1(MiddlewareMixin):
        def process_request(self, request):
            print("md1 process_request method.", id(request)) # Vor der View ausführen

        def process_response(self,request, response): :# Basierend auf request/response
            print("md1 process_response method!", id(request)) # Nach der View
            return response

        def process_view(self,request, view_func, view_args, view_kwargs):
            print(md1 process_view method!) # Vor der View ausführen; nacheinander ausführen
            #return view_func(request)


        def process_exception(self, request, exception):# Diese Methode wird nur ausgelöst, wenn ein Fehler auftritt
            print(md1 process_exception Methode!)
            # return HttpResponse(exception) # Fehlermeldung zurückgeben

    Weitere Erweiterungen