Writing middleware in Django>=1.10

Since Django 1.10, a middleware class must accept a get_response argument in its __init__() method and provide a __call__() method. Although this can be achieved by using the django.utils.deprecation.MiddlewareMixin when defining a middleware class (as shown in the answer by W.Perrin), creating a class-based middleware in the currently supported versions of Django looks like this:

class CustomMiddleware(object):
    def __init__(self, get_response):
        """
        One-time configuration and initialisation.
        """
        self.get_response = get_response

    def __call__(self, request):
        """
        Code to be executed for each request before the view (and later
        middleware) are called.
        """
        response = self.get_response(request)
        return response

    def process_view(self, request, view_func, view_args, view_kwargs):
        """
        Called just before Django calls the view.
        """
        return None

    def process_exception(self, request, exception):
        """
        Called when a view raises an exception.
        """
        return None

    def process_template_response(self, request, response):
        """
        Called just after the view has finished executing.
        """
        return response

The process_view(), process_exception() and process_template_response() are special hooks, called by Django when processing the middleware, you may define in your middleware class. In the example above, the implemented hooks will do nothing special expect for making sure that Django will call the next middleware to further process the response/request.

Activating middleware

To activate the middleware component, add it to the MIDDLEWARE list in your Django settings.

MIDDLEWARE = [
    # Default Django 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',

    # Add your custom middleware
    'path.to.your.middleware.CustomMiddleware',
]

Just two steps. It works for me with django2.1.

1.Create your own Middleware class.

There is a good demo from official manual.

https://docs.djangoproject.com/en/2.1/ref/request-response/#django.http.HttpRequest.get_host

    from django.utils.deprecation import MiddlewareMixin

    class MultipleProxyMiddleware(MiddlewareMixin):
        FORWARDED_FOR_FIELDS = [
            'HTTP_X_FORWARDED_FOR',
            'HTTP_X_FORWARDED_HOST',
            'HTTP_X_FORWARDED_SERVER',
        ]

        def process_request(self, request):
            """
            Rewrites the proxy headers so that only the most
            recent proxy is used.
            """
            for field in self.FORWARDED_FOR_FIELDS:
                if field in request.META:
                    if ',' in request.META[field]:
                        parts = request.META[field].split(',')
                        request.META[field] = parts[-1].strip()

2.Reference your Middleware class in the MIDDLEWARE list of your project setting.py file.

The rule for Middleware reference is the path to your class from the root directory of your project.

For example, in a project named mysite,the tree is as follow.

├── mysite
│   ├── manage.py
│   ├── mysite
│   │   ├── __init__.py
│   │   ├── middleware.py
│   │   ├── settings.py
│   │   ├── urls.py
│   │   └── wsgi.py

We just add our Middleware class MultipleProxyMiddleware in the middleware.py file. We get the following reference name.

MIDDLEWARE = [
    'mysite.middleware.MultipleProxyMiddleware',  
     ...
]

First, middleware is actually the bridge between Httprequest and HttpResponse, it’s normally globally, because it’s the bridge, because the HttpRequest must walk the bridge to reach the server and walk the bridge back to the client with the HttpResponse.
It’s supercool, which means you can write a bunch of method to be run before the request hit the server,or after the request hit the server.
Take the csrfmiddleware as an example, the request will first be judged by the middleware whether it’s method is POST, if true, then middleware will compare the csrf_token it possessed with the token stored inside the server, this token is generated when you send the HTML with the form tag, because normally, client will only be able to send POST request through the form server directly send to the client, so server can use this to judge whether this POST is from the form server sent to you, and combined with authentication or authorization, decide whether to send the reqeust to the server or just object the request overall.
So,when you write your own middleware, be clear about what you want to do with the request or response, do you want to add an element in the response? Like the messagemiddleware did, this new element can be seen as the context django view send or you want to add session, and check the session everytime the client make a request, with this mindset, follow some fixed format, like in this websitehttps://medium.com/scalereal/everything-you-need-to-know-about-middleware-in-django-2a3bd3853cd6.

For example, create middleware folder with __init__.py(Empty file) and custom.py in core/ as shown below: *I referred to the doc and I use Django 4.2.3:

django-project
 |-core
 |  |-settings.py
 |  └-middleware # Here
 |     |-__init__.py
 |     └-custom.py
 |-my_app1
 └-my_app2

Then, put the code below to custom.py:

# "core/middleware/custom.py"

def simple_middleware(get_response):
    print("Here is run only once when the server starts")

    def middleware(request):

        print("Here is run before a view is run")

        response = get_response(request)

        print("Here is run after a view is run")

        return response

    return middleware

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        print("Here is run only once when the server starts")

    def __call__(self, request):

        print("Here is run before a view is run")

        response = self.get_response(request)

        print("Here is run after a view is run")

        return response

Finally, set simple_middleware and SimpleMiddleware to MIDDLEWARE, then every time you load a django website, the middlewares you set to MIDDLEWARE are run:

# "core/settings.py"

...

MIDDLEWARE = [
    ...
    'core.middleware.custom.simple_middleware', # Here
    'core.middleware.custom.SimpleMiddleware' # Here
]

...

It will be helpful in the case of When you know what type of Exception occurs in the views.
From the above I have Created my own Custom class like

from .models import userDetails

class customMiddleware(object):

    def process_request(self,request):
        result=''
        users = userDetails.objects.all()
        print '-->',users ,'---From middleware calling ---'

        username=request.POST.get("username")
        salary = request.POST.get("salary")
        if salary:
            try:
                result = username+int(salary)
            except:
                print "Can't add"

It will be executed when the exception occur in the case of string and integer addition.

You can write Corresponding views for above middleware class