← Back to Django Course | Chapter 12: Signals & Middleware | Lesson 5 of 8

Introduction to Django Middleware

Middleware is like a series of checkpoints every request passes through on its way to your view and back.

In this page:

  1. What Is Middleware?
  2. The Request/Response Chain
  3. Built-in Middleware You Already Use
  4. Where Middleware Lives

What Is Middleware?

Middleware is a class that sits between Django's request handling and your view, able to run code before and after the view executes.

Example: What Is Middleware?

Middleware is a class that sits between Django's request handling and your view, able to run code before and after the view executes.

markup 
class SimpleLoggingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        print(f"Request path: {request.path}")
        response = self.get_response(request)
        return response
{# Django-only code -- models.py/views.py/urls.py/settings.py snippets, or template markup using Django template tags/variables -- can't run standalone via Judge0 or the browser preview, since it needs a real Django project. Only this course's pure-Python examples (example_lang == 'python', no Django imports) are actually runnable, so those still get the button below. #}

The Request/Response Chain

Calling self.get_response(request) hands control to the next middleware (or the view). Code before that call runs on the way in; code after runs on the way out.

Example: The Request/Response Chain

Calling self.get_response(request) hands control to the next middleware (or the view). Code before that call runs on the way in; code after runs on the way out.

markup 
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        print("Before view runs")
        response = self.get_response(request)
        print("After view runs")
        return response
{# Django-only code -- models.py/views.py/urls.py/settings.py snippets, or template markup using Django template tags/variables -- can't run standalone via Judge0 or the browser preview, since it needs a real Django project. Only this course's pure-Python examples (example_lang == 'python', no Django imports) are actually runnable, so those still get the button below. #}

Built-in Middleware You Already Use

Every new Django project ships with middleware for security headers, sessions, and authentication already enabled in settings.py.

Example: Built-in Middleware You Already Use

Every new Django project ships with middleware for security headers, sessions, and authentication already enabled in settings.py.

markup 
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
]
{# Django-only code -- models.py/views.py/urls.py/settings.py snippets, or template markup using Django template tags/variables -- can't run standalone via Judge0 or the browser preview, since it needs a real Django project. Only this course's pure-Python examples (example_lang == 'python', no Django imports) are actually runnable, so those still get the button below. #}

Where Middleware Lives

Middleware is registered in settings.py as a dotted Python path, whether it's one of Django's own or one you wrote yourself.

Example: Where Middleware Lives

Middleware is registered in settings.py as a dotted Python path, whether it's one of Django's own or one you wrote yourself.

markup 
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "myapp.middleware.SimpleLoggingMiddleware",
]
{# Django-only code -- models.py/views.py/urls.py/settings.py snippets, or template markup using Django template tags/variables -- can't run standalone via Judge0 or the browser preview, since it needs a real Django project. Only this course's pure-Python examples (example_lang == 'python', no Django imports) are actually runnable, so those still get the button below. #}
Common Mistakes
  1. Thinking middleware only runs before the view — it also runs on the way back with the response.
  2. Forgetting that MIDDLEWARE order in settings.py determines the request/response processing order.
  3. Doing heavy work in middleware that runs on every single request, even ones that don't need it.
Chapter Summary
  • Middleware wraps every request/response cycle in Django.
  • Each middleware can inspect or modify the request before the view runs, and the response after.
  • Django ships with useful built-in middleware for security, sessions, and authentication.
  • The order of MIDDLEWARE in settings.py matters — it forms a chain.
🔒

Chapter Quiz — Complete all 8 topics to unlock

0/8 topics done

Complete these topics first:

← Previous Lesson Connecting Signals to Receivers Next Lesson → Writing Custom Middleware

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.