Middleware: Built-in and Custom in Django

Middleware in Django acts as lightweight components placed between the web server and the views. They process requests and responses globally, helping manage common tasks without complicating view code.

• Wrap reusable functionality, such as CSRF protection, into separate components.
• Apply automatically to all incoming requests and outgoing responses.
• Support both class-based and function-based middleware styles.
• Handle cross-cutting tasks like authentication, security headers, and session management.
• Useful for global operations such as enforcing HTTPS, compressing responses, or logging performance.

Working of Middleware

Django integrates middleware at multiple stages of the request-response cycle:

1. Request Phase: The request passes through each middleware in the order defined in the MIDDLEWARE setting (top-to-bottom). Middleware can:

• Inspect or modify the request.
• Short-circuit processing by returning an HttpResponse early.
• Return None to continue processing.

2. URL Resolution and View Processing: After passing the middleware stack, the request reaches Django's URL resolver, which executes the matched view function or class-based view to generate a response.

3. Response Phase: The response passes back through the middleware stack in reverse order (bottom-to-top). Middleware can:

• Modify the response (e.g., add headers).
• Return a modified response upstream.

4. Exception Handling (Optional):
If an exception occurs during view processing, a process_exception hook in middleware can intervene before the response phase.

This structure ensures that middleware can inject functionality at multiple points in the request-response lifecycle while remaining modular, reusable, and decoupled from individual views.

Middleware Hooks in Django

Hooks are special methods in Django middleware that are called at specific points during the request-response cycle. They allow inspection, modification, or short-circuiting of requests and responses in a modular and reusable way.

• process_request(request): Runs before the view executes. Can inspect or modify the request. Returning an HttpResponse here stops further processing.
• process_view(request, view_func, view_args, view_kwargs): Runs after URL resolution but before the view executes. Useful for performing view-specific checks or modifications.
• process_template_response(request, response): Runs after the view returns a TemplateResponse. Allows adjustments to the template or context before rendering.
• process_exception(request, exception): Invoked if a view raises an exception. Can handle the exception and return a custom response.
• process_response(request, response): Runs after the view has returned a response (or after process_exception). Allows final modifications before sending the response back to the client

Types of Middleware in Django

Django's middleware can be divided into 2 types: built-in and custom.

Built-in Django Middleware

Django includes a robust set of built-in middleware classes, enabled by default in new projects. Below is a comprehensive overview including their purposes and key settings:

The default MIDDLEWARE in settings.py includes most of these. Customize as needed, but maintain order for dependencies (e.g., sessions before auth).
Example:

Custom Middleware

Custom middleware allows the implementation of application-specific logic that isn’t covered by Django’s built-in middleware. Django supports two approaches for creating custom middleware:

1. Class-based Middleware

• Typically inherits from MiddlewareMixin or implements the required hooks directly.
• Provides clear structure with multiple hooks for process_request, process_view, process_exception, and process_response.
• Ideal for more complex or reusable middleware components.

2. Function-based Middleware

• A simple callable that accepts a get_response argument and returns a response.
• Suitable for lightweight or one-off processing tasks

Implementation Steps:

1. Create a middleware.py file inside your Django app.
2. Define the middleware class or function with the desired logic.
3. Add the middleware to the MIDDLEWARE list in settings.py at the appropriate position in the stack.

Create Custom Middleware in Django

Suppose a Django project has three types of users: Teacher, Student, and Principal. The goal of the middleware is to redirect users to their respective home pages after login:

• Teacher: Redirected to the teacher’s homepage
• Student: Redirected to the student’s homepage
• Principal: Redirected to the principal’s homepage

Setting up the Project

Consider a project  named 'projectmiddleware' having an app named 'testapp'.

Creating Necessary Files

In views.py:

This file manages user authentication, user registration, and user-specific homepages, acting as the central component for handling user interactions.

• Functions for login and registration
• Views for teacher_home, student_home, and principal_home
• Logic to display content based on the logged-in user type

In models.py:

This file defines a custom user model, CustomUser, which extends Django’s AbstractUser. It adds a role field to categorize users as teacher, student, or principal, enabling role-based behavior and access control within the application.

In forms.py:

This Django file defines a custom user creation form, CustomUserCreationForm, which extends UserCreationForm. It includes a role field, allowing users to select their role (teacher, student, or principal) during registration. This ensures consistency with the role-based functionality of the custom user model.

In custom_middleware.py:

This Django middleware, CustomMiddleware, injects custom logic into the request-processing flow. It intercepts requests for login, logout, and the admin panel, handling them appropriately. For authenticated users, it redirects them to their designated home page based on their role (teacher, student, or principal), ensuring a role-specific navigation experience.

In admin.py:

This Django admin configuration manages the CustomUser model within the admin panel. It customizes the displayed fields and registers the model, allowing administrators to efficiently manage users and their roles.

In urls.py:

This Django URL configuration maps incoming URLs to the appropriate view functions within the testapp application. It defines routes for admin access, user authentication, and role-based home pages, ensuring that each URL points to its corresponding view logic.

Setting up GUI

home.html: This is a homepage created in HTML.

login.html: This is the login page which is used to collect the credentials from the user and then pass them to the backend.

signup.html: This is the signup page which is used to collect the credentials from the user and then register the user.

student.html: This is the homepage for student.

teacher.html: This is the homepage for Teacher.

principal.html: This is the homepage for principal.

Deploying the Project:

Apply migrations to set up the database:

python manage.py makemigrations

python manage.py migrate

Start the development server:

python3 manage.py runserver

This will launch the Django application locally, allowing you to access it via the default URL http://127.0.0.1:8000/.

Output Video:

👁 ezgifcom-optimize