Authentication middleware in Django - Step-by-Step Execution

Concept Flow - Authentication middleware

Request received

↓

Middleware invoked

↓

Check if user is authenticated

↓

Allow request

↓

View processes request

↓

Response sent back

The middleware intercepts each request, checks if the user is logged in, and either allows the request to continue or redirects to login.

Execution Sample

Django

from django.shortcuts import redirect

class AuthMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if not request.user.is_authenticated:
            return redirect('/login/')
        return self.get_response(request)

This middleware checks if the user is authenticated; if not, it redirects to the login page, otherwise it passes the request to the view.

Execution Table

Step	Request.user.is_authenticated	Action	Result
1	False	Check authentication	Redirect to /login/
2	True	Check authentication	Pass request to view
3	-	View processes request	Response generated
4	-	Response sent back	Request cycle ends

💡 Request ends after redirect or after view processes authenticated request

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
request.user.is_authenticated	Depends on user	False or True	True if passed	N/A
response	None	Redirect or None	View response or None	Final HTTP response

Key Moments - 2 Insights

Why does the middleware redirect instead of letting the request continue?

Because the user is not authenticated (see execution_table step 1), the middleware stops the request flow and redirects to login to protect secure pages.

What happens if the user is authenticated?

The middleware passes the request to the view (execution_table step 2), allowing normal processing and response generation.

Visual Quiz - 3 Questions

Look at the execution table, what happens at step 1 when user is not authenticated?

A Request is redirected to login page

B Request is passed to the view

C Response is sent back immediately

D Middleware raises an error

💡 Hint

Check the 'Action' and 'Result' columns at step 1 in execution_table

At which step does the view process the request?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look for 'View processes request' in the 'Action' column of execution_table

If request.user.is_authenticated is always True, how does the execution_table change?

A Step 3 is skipped

B Step 1 redirects to login

C Step 1 passes request to view, no redirect

D Response is never sent

💡 Hint

Refer to 'request.user.is_authenticated' values and actions in execution_table steps 1 and 2

Concept Snapshot

Authentication middleware intercepts requests.
Checks if user is logged in.
If not, redirects to login page.
If yes, passes request to view.
Protects secure pages from unauthorized access.

Full Transcript

Authentication middleware in Django runs on every request. It checks if the user is logged in by inspecting request.user.is_authenticated. If the user is not authenticated, the middleware redirects the request to the login page, stopping further processing. If the user is authenticated, the middleware allows the request to continue to the view, which then processes the request and returns a response. This ensures only logged-in users can access protected pages.

Practice

1. What is the main purpose of Django's AuthenticationMiddleware?

easy

A. To serve static files like CSS and JavaScript

B. To handle database connections automatically

C. To attach the authenticated user to request.user on every request

D. To manage URL routing and view dispatching

Solution

1. Step 1: Understand middleware role

   AuthenticationMiddleware processes each request to identify the user making it.

2. Step 2: Check what it attaches to request

   It adds the user object to request.user so views can access user info easily.

3. Final Answer:

   To attach the authenticated user to request.user on every request -> Option C

4. Quick Check:

   AuthenticationMiddleware = attaches user info [OK]

Hint: AuthenticationMiddleware sets request.user for user info [OK]

Common Mistakes:

• Confusing it with static file handling middleware
• Thinking it manages database connections
• Assuming it handles URL routing

2. Which of the following is the correct way to add AuthenticationMiddleware in Django's settings.py?

easy

A. 'django.contrib.auth.middleware.AuthenticationMiddleware' must be listed after 'django.contrib.sessions.middleware.SessionMiddleware'

B. 'django.contrib.auth.middleware.AuthenticationMiddleware' must be listed before 'django.contrib.sessions.middleware.SessionMiddleware'

C. 'django.contrib.auth.middleware.AuthenticationMiddleware' can be anywhere in the list

D. 'django.contrib.auth.middleware.AuthenticationMiddleware' should be the first middleware in the list

Solution

1. Step 1: Recall middleware order importance

   SessionMiddleware must run before AuthenticationMiddleware because authentication depends on session data.

2. Step 2: Confirm correct order

   AuthenticationMiddleware should be listed after SessionMiddleware in the MIDDLEWARE list.

3. Final Answer:

   AuthenticationMiddleware must be listed after SessionMiddleware -> Option A

4. Quick Check:

   SessionMiddleware before AuthenticationMiddleware [OK]

Hint: AuthenticationMiddleware comes after SessionMiddleware in settings [OK]

Common Mistakes:

• Placing AuthenticationMiddleware before SessionMiddleware
• Ignoring middleware order importance
• Assuming order does not matter

3. Given this Django view code snippet, what will print(request.user.is_authenticated) output if the user is logged in?

medium

A. Raises AttributeError

B. False

C. None

D. True

Solution

1. Step 1: Understand request.user with AuthenticationMiddleware

   When AuthenticationMiddleware is enabled, request.user is a User object or AnonymousUser.

2. Step 2: Check is_authenticated property for logged-in user

   For logged-in users, request.user.is_authenticated returns True.

3. Final Answer:

   True -> Option D

4. Quick Check:

   Logged-in user means is_authenticated = True [OK]

Hint: request.user.is_authenticated is True if logged in [OK]

Common Mistakes:

• Expecting False for logged-in users
• Thinking it returns None
• Assuming it raises an error

4. You added AuthenticationMiddleware to your Django project but request.user is always AnonymousUser. What is the most likely cause?

medium

A. You forgot to add "django.contrib.sessions.middleware.SessionMiddleware" before AuthenticationMiddleware

B. You did not import AuthenticationMiddleware in your views.py

C. You need to restart the database server

D. You must add AuthenticationMiddleware to INSTALLED_APPS

Solution

1. Step 1: Understand dependency on session middleware

   AuthenticationMiddleware relies on session data to identify users, so SessionMiddleware must run first.

2. Step 2: Identify missing or misordered middleware

   If SessionMiddleware is missing or placed after AuthenticationMiddleware, user info won't load, causing AnonymousUser.

3. Final Answer:

   Forgot to add SessionMiddleware before AuthenticationMiddleware -> Option A

4. Quick Check:

   SessionMiddleware missing or misplaced causes AnonymousUser [OK]

Hint: SessionMiddleware must come before AuthenticationMiddleware [OK]

Common Mistakes:

• Thinking you must import middleware in views
• Restarting database unrelated to middleware
• Adding middleware to INSTALLED_APPS instead of MIDDLEWARE

5. You want to create a custom middleware that only allows authenticated users to access certain views. Which is the best way to use Django's AuthenticationMiddleware to achieve this?

hard

A. Use AuthenticationMiddleware only in views, not in middleware

B. Add AuthenticationMiddleware to MIDDLEWARE, then check request.user.is_authenticated in your custom middleware before view runs

C. Add AuthenticationMiddleware after your custom middleware in MIDDLEWARE list

D. Replace AuthenticationMiddleware with your custom middleware that handles authentication manually

Solution

1. Step 1: Use AuthenticationMiddleware to set request.user

   AuthenticationMiddleware must be in MIDDLEWARE to provide user info on requests.

2. Step 2: Implement custom middleware after AuthenticationMiddleware

   Your custom middleware can check request.user.is_authenticated to allow or block access before views run.

3. Final Answer:

   Add AuthenticationMiddleware to MIDDLEWARE, then check request.user.is_authenticated in your custom middleware before view runs -> Option B

4. Quick Check:

   AuthenticationMiddleware first, then custom auth check [OK]

Hint: Check request.user.is_authenticated in custom middleware after AuthenticationMiddleware [OK]

Common Mistakes:

• Replacing AuthenticationMiddleware instead of extending it
• Placing AuthenticationMiddleware after custom middleware
• Trying to use AuthenticationMiddleware only inside views