Settings में Middleware Order
In this page:
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware', # runs first on requests
'app_name.middleware.MiddlewareName',
# ... last item runs closest to the view
]
Requests Top से Bottom जाती हैं
एक incoming request के लिए, Django हर middleware का pre-view code इसी order में चलाता है जिस order में यह listed है, top से bottom।
उदाहरण: Requests Go Top to Bottom
For an incoming request, Django runs each middleware's pre-view code in the order it's listed, top to bottom.
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware", # 1st on request
"django.contrib.sessions.middleware.SessionMiddleware", # 2nd
"myapp.middleware.CustomHeaderMiddleware", # 3rd
]
{# 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. #}
Responses Bottom से Top जाती हैं
वापस जाते समय, order reverse हो जाता है: जो middleware request को आखिरी बार touch करता है वह response को पहली बार touch करने वाला होता है।
उदाहरण: Responses Go Bottom to Top
On the way back out, the order reverses: the last middleware to touch the request is the first to touch the response.
class OrderDemoMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
print("-> request enters here first (top of list)")
response = self.get_response(request)
print("<- response leaves here last (top of list)")
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 के बीच Dependencies
कुछ built-in middleware किसी और के पहले चलने पर depend करता है — उदाहरण के लिए, AuthenticationMiddleware request.session पढ़ता है, इसलिए SessionMiddleware को इससे पहले आना चाहिए।
उदाहरण: Dependencies Between Built-in Middleware
Some built-in middleware relies on another running first — for example, AuthenticationMiddleware reads request.session, so SessionMiddleware must come before it.
MIDDLEWARE = [
"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. #}
- Custom middleware को SecurityMiddleware या SessionMiddleware से पहले रखना जब यह sessions या security headers पर depend करता है जो पहले से set up होने चाहिए।
- यह मान लेना कि response processing उसी order में होता है जैसे request processing — यह असल में reverse में होता है।
- MIDDLEWARE को बिना test किए reorder करना, authentication break करते हुए क्योंकि AuthenticationMiddleware को पहले SessionMiddleware चलने की ज़रूरत है।
- settings.py में MIDDLEWARE requests के लिए एक top-to-bottom list है, और responses के लिए bottom-to-top।
- कुछ middleware दूसरों के पहले चलने पर depend करता है, जैसे AuthenticationMiddleware को SessionMiddleware की ज़रूरत।
- Custom middleware को गलत position में रखना चुपचाप session या auth behavior break कर सकता है।
- अगर doubt हो, तो custom middleware को Django के built-ins के बाद, list के आखिर के पास जोड़ें।
Chapter Quiz — Complete all 8 topics to unlock
0/8 topics done
Complete these topics first: