Django 2.1

Middleware




django

Middleware

मिडिलवेयर Django के अनुरोध / प्रतिक्रिया प्रसंस्करण में हुक की एक रूपरेखा है। यह विश्व स्तर पर Django के इनपुट या आउटपुट को बदलने के लिए एक हल्का, निम्न-स्तरीय "प्लगइन" प्रणाली है।

प्रत्येक मिडलवेयर घटक कुछ विशिष्ट कार्य करने के लिए जिम्मेदार होता है। उदाहरण के लिए, Django में एक मिडलवेयर घटक, AuthenticationMiddleware , जो सत्रों का उपयोग करने वाले अनुरोधों के साथ उपयोगकर्ताओं को जोड़ता है।

यह दस्तावेज़ बताता है कि मिडलवेयर कैसे काम करता है, आप मिडलवेयर को कैसे सक्रिय करते हैं, और अपना मिडलवेयर कैसे लिखें। Django जहाज कुछ बिल्ट-इन मिडलवेयर के साथ आप सही बॉक्स से बाहर का उपयोग कर सकते हैं। वे बिल्ट-इन मिडलवेयर संदर्भ में प्रलेखित हैं।

अपना खुद का मिडलवेयर लिखना

एक मिडलवेयर फैक्ट्री एक get_response योग्य है जो get_response योग्य get_response और एक मिडलवेयर लौटाता है। एक मिडलवेयर एक कॉल करने योग्य है जो एक अनुरोध लेता है और एक दृश्य की तरह, प्रतिक्रिया देता है।

एक मिडलवेयर को एक फ़ंक्शन के रूप में लिखा जा सकता है जो इस तरह दिखता है:

def simple_middleware(get_response):
    # One-time configuration and initialization.

    def middleware(request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        response = get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

    return middleware

या इसे एक ऐसे वर्ग के रूप में लिखा जा सकता है जिसके उदाहरण कॉल करने योग्य हों, जैसे:

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        response = self.get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

Django द्वारा प्रदान किया जाने वाला get_response वास्तविक हो सकता है (यदि यह अंतिम सूचीबद्ध मिडलवेयर है) या यह श्रृंखला में अगला मिडलवेयर हो सकता है। वर्तमान मिडलवेयर को यह जानने या देखभाल करने की आवश्यकता नहीं है कि वास्तव में यह क्या है, बस यह कि जो भी आगे आता है उसका प्रतिनिधित्व करता है।

उपरोक्त थोड़ा सा सरलीकरण है - श्रृंखला में अंतिम मिडलवेयर के लिए get_response callable वास्तविक दृश्य नहीं होगा, बल्कि हैंडलर से एक आवरण विधि है जो दृश्य मिडलवेयर को लागू करने, उपयुक्त URL तर्कों के साथ दृश्य को कॉल करने और आवेदन करने का ध्यान रखती है। template-response और exception मिडलवेयर।

मिडिलवेयर आपके पाइथन पथ पर कहीं भी रह सकता है।

__init__(get_response)

Middleware कारखानों एक get_response तर्क को स्वीकार करना चाहिए। आप मिडलवेयर के लिए कुछ वैश्विक स्थिति को इनिशियलाइज़ भी कर सकते हैं। ध्यान रखें कि दो जोड़े हैं:

  • Django केवल get_response तर्क के साथ आपके मिडलवेयर को इनिशियलाइज़ get_response है, इसलिए आप __init__() को किसी अन्य तर्क के रूप में परिभाषित नहीं कर सकते हैं।
  • __call__() पद्धति के विपरीत जिसे अनुरोध के अनुसार एक बार कहा जाता है, __init__() केवल एक बार कहा जाता है, जब वेब सर्वर शुरू होता है।

मिडिलवेयर को अप्रयुक्त के रूप में चिह्नित करना

स्टार्टअप समय पर यह निर्धारित करना कभी-कभी उपयोगी होता है कि क्या मिडलवेयर का एक टुकड़ा इस्तेमाल किया जाना चाहिए। इन मामलों में, आपके मिडलवेयर का __init__() विधि MiddlewareNotUsed को बढ़ा सकता है। Django तब मिडलवेयर प्रक्रिया से उस मिडलवेयर को हटा देगा और DEBUG True होने पर django.request लॉगर पर डिबग मैसेज लॉग इन कर django.request

मिडलवेयर को सक्रिय करना

एक मिडिलवेयर घटक को सक्रिय करने के लिए, इसे अपने Django सेटिंग्स में MIDDLEWARE सूची में जोड़ें।

MIDDLEWARE , प्रत्येक मिडलवेयर घटक को एक स्ट्रिंग द्वारा दर्शाया गया है: मिडिलवेयर फैक्ट्री के वर्ग या फ़ंक्शन नाम के लिए पूर्ण पायथन पथ। उदाहरण के लिए, यहां django-admin startproject द्वारा बनाया गया डिफ़ॉल्ट मान है:

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',
]

एक Django स्थापना के लिए किसी मिडलवेयर की आवश्यकता नहीं होती है - यदि आप चाहें तो MIDDLEWARE खाली हो सकता है - लेकिन यह दृढ़ता से सुझाव दिया जाता है कि आप कम से कम CommonMiddleware उपयोग CommonMiddleware

MIDDLEWARE में आदेश मायने रखता है क्योंकि एक मिडलवेयर अन्य मिडलवेयर पर निर्भर हो सकता है। उदाहरण के लिए, AuthenticationMiddleware सत्र में प्रमाणित उपयोगकर्ता को संग्रहीत करता है; इसलिए, यह SessionMiddleware बाद चलना चाहिए। Django मिडलवेयर वर्गों के आदेश के बारे में कुछ सामान्य संकेत के लिए मिडिलवेयर ऑर्डर देखें।

मिडलवेयर ऑर्डर और लेयरिंग

अनुरोध चरण के दौरान, दृश्य को कॉल करने से पहले, Django MIDDLEWARE , टॉप-डाउन में परिभाषित किए गए क्रम में मिडिलवेयर लागू करता है।

आप इसे प्याज की तरह सोच सकते हैं: प्रत्येक मिडलवेयर क्लास एक "परत" है जो दृश्य को लपेटता है, जो प्याज के मूल में है। यदि अनुरोध प्याज की सभी परतों से होकर गुजरता है (प्रत्येक कॉल get_response को अगली परत में अनुरोध पास करने के लिए), कोर पर देखने के लिए सभी तरह से, प्रतिक्रिया तब हर परत (रिवर्स ऑर्डर में) से होकर get_response वापस बाहर रास्ते पर।

यदि परतों में से एक शॉर्ट-सर्किट का फैसला करता है और कभी भी उसके get_response कॉल किए बिना प्रतिक्रिया get_response , तो उस परत (दृश्य सहित) के अंदर प्याज की परतों में से कोई भी अनुरोध या प्रतिक्रिया नहीं देखेगा। प्रतिक्रिया केवल उन्हीं परतों से होकर गुज़रेगी, जिनमें अनुरोध गुजरा था।

अन्य मिडलवेयर हुक

पहले वर्णित मूल अनुरोध / प्रतिक्रिया मिडलवेयर पैटर्न के अलावा, आप कक्षा-आधारित मिडलवेयर में तीन अन्य विशेष विधियाँ जोड़ सकते हैं:

process_view()

process_view(request, view_func, view_args, view_kwargs)

request एक HttpRequest ऑब्जेक्ट है। view_func पायथन फ़ंक्शन है जिसे Django उपयोग करने वाला है। (यह वास्तविक फ़ंक्शन ऑब्जेक्ट है, स्ट्रिंग के रूप में फ़ंक्शन का नाम नहीं है।) view_args स्थितीय तर्कों की एक सूची है जिसे दृश्य में पास किया जाएगा, और view_kwargs कीवर्ड तर्कों का एक शब्दकोष है जिसे दृश्य में पारित किया जाएगा। न तो view_args और न ही view_kwargs में पहले दृश्य तर्क ( request ) शामिल हैं।

Django के दृश्य को कॉल करने से ठीक पहले process_view() को कॉल किया जाता है।

इसे या तो None भी None लौटना चाहिए या HttpResponse ऑब्जेक्ट। यदि यह None लौटाता है, तो Django इस अनुरोध को संसाधित करना जारी रखेगा, किसी भी अन्य process_view() मिडलवेयर और फिर, उपयुक्त दृश्य को निष्पादित करना। यदि यह एक HttpResponse ऑब्जेक्ट देता है, तो Django उपयुक्त दृश्य को कॉल करने से परेशान नहीं करेगा; यह उस HttpResponse पर प्रतिक्रिया मिडिलवेयर लागू करेगा और परिणाम लौटाएगा।

ध्यान दें

देखने के चलने से पहले या process_view() में मिडलवेयर के अंदर process_view() , मिडलवेयर के बाद चलने वाले किसी भी व्यू को रिक्वेस्ट के लिए अपलोड हैंडलर को संशोधित करने में सक्षम होने से रोकेगा, और आम तौर पर इससे बचना चाहिए।

CsrfViewMiddleware वर्ग को एक अपवाद माना जा सकता है, क्योंकि यह csrf_exempt() और csrf_protect() सज्जाकार प्रदान करता है जो CSRF मान्यताओं के होने के बिंदु पर स्पष्ट रूप से विचार करने की अनुमति देते हैं।

process_exception()

process_exception(request, exception)

request एक HttpRequest ऑब्जेक्ट है। exception एक Exception वस्तु है जिसे दृश्य फ़ंक्शन द्वारा उठाया गया है।

जब कोई दृश्य अपवाद को उठाता है, तो Django process_exception() कहता है। process_exception() None या कोई HttpResponse ऑब्जेक्ट None लौटना चाहिए। यदि यह एक HttpResponse ऑब्जेक्ट देता है, तो टेम्पलेट प्रतिक्रिया और प्रतिक्रिया मिडलवेयर लागू किया जाएगा और परिणामस्वरूप प्रतिक्रिया ब्राउज़र में वापस आ जाएगी। अन्यथा, डिफ़ॉल्ट अपवाद हैंडलिंग kicks में।

फिर से, मिडलवेयर को प्रतिक्रिया चरण के दौरान रिवर्स ऑर्डर में चलाया जाता है, जिसमें process_exception शामिल हैं। यदि कोई अपवाद मिडलवेयर प्रतिक्रिया देता है, तो मिडिलवेयर क्लासेस के ऊपर के process_exception के process_exception तरीकों को बिल्कुल भी नहीं बुलाया जाएगा।

process_template_response()

process_template_response(request, response)

request एक HttpRequest ऑब्जेक्ट है। response TemplateResponse ऑब्जेक्ट (या समतुल्य) एक Django दृश्य या एक मिडलवेयर द्वारा लौटाया गया है।

process_template_response() जवाब आवृत्ति के पास एक render() विधि होती है, तो यह दर्शाता है कि यह एक TemplateResponse या समकक्ष है, इसके बाद ही process_template_response() कहा जाता है।

यह एक प्रतिक्रिया वस्तु वापस करना चाहिए जो एक render विधि को लागू करता है। यह response.template_name और response को बदलकर दी गई response को बदल सकता है, या यह एक नया-नया TemplateResponse कर सकता है या बराबर कर सकता है।

आपको स्पष्ट रूप से प्रतिक्रियाओं को प्रस्तुत करने की आवश्यकता नहीं है - सभी टेम्पलेट प्रतिक्रिया मिडलवेयर को कॉल किए जाने के बाद प्रतिक्रियाएं स्वचालित रूप से प्रदान की जाएंगी।

मिडिलवेयर प्रतिक्रिया चरण के दौरान रिवर्स ऑर्डर में चलाया जाता है, जिसमें process_template_response()

स्ट्रीमिंग प्रतिक्रियाओं से निपटना

HttpResponse विपरीत, StreamingHttpResponse में content विशेषता नहीं है। नतीजतन, मिडलवेयर अब यह नहीं मान सकता है कि सभी प्रतिक्रियाओं में एक content विशेषता होगी। यदि उन्हें सामग्री तक पहुंच की आवश्यकता है, तो उन्हें स्ट्रीमिंग प्रतिक्रियाओं के लिए परीक्षण करना होगा और तदनुसार अपने व्यवहार को समायोजित करना होगा:

if response.streaming:
    response.streaming_content = wrap_streaming_content(response.streaming_content)
else:
    response.content = alter_content(response.content)

ध्यान दें

streaming_content कॉन्टेंट को स्मृति में रखने के लिए बहुत बड़ा माना जाना चाहिए। रिस्पांस मिडलवेयर इसे एक नए जनरेटर में लपेट सकता है, लेकिन इसका उपभोग नहीं करना चाहिए। रैपिंग को आमतौर पर इस प्रकार लागू किया जाता है:

def wrap_streaming_content(content):
    for chunk in content:
        yield alter_content(chunk)

उपवाद सम्भालना

Django स्वचालित रूप से एक दृश्य स्थिति कोड के साथ एक उपयुक्त HTTP प्रतिक्रिया में दृश्य या मिडलवेयर द्वारा उठाए गए अपवादों को परिवर्तित करता है। कुछ अपवादों को 4xx स्थिति कोड में बदल दिया जाता है, जबकि एक अज्ञात अपवाद को 500 स्थिति कोड में बदल दिया जाता है।

यह रूपांतरण प्रत्येक मिडलवेयर के पहले और बाद में होता है (आप इसे प्याज की प्रत्येक परत के बीच की पतली फिल्म के रूप में सोच सकते हैं), ताकि प्रत्येक मिडलवेयर हमेशा अपने get_response को कॉल करने get_response कॉल से किसी प्रकार की HTTP प्रतिक्रिया प्राप्त करने पर भरोसा कर get_response । मिडलवेयर को एक try/except अपवाद try/except get_response में अपने कॉल को लपेटने के बारे में चिंता करने की ज़रूरत नहीं है और एक अपवाद try/except संभालना जो बाद के मिडलवेयर या व्यू द्वारा उठाया गया हो। भले ही श्रृंखला में अगले मिडलवेयर एक Http404 अपवाद को उठाता है, उदाहरण के लिए, आपके मिडलवेयर को वह अपवाद दिखाई नहीं देगा; इसके बजाय इसे 404 की status_code के साथ एक HttpResponse ऑब्जेक्ट मिलेगा।

उन्नयन पूर्व Django 1.10 शैली मिडलवेयर

class django.utils.deprecation.MiddlewareMixin

Django, django.utils.deprecation.MiddlewareMixin प्रदान करता है django.utils.deprecation.MiddlewareMixin मिडलवेयर क्लासेस बनाने में आसानी हो जो कि MIDDLEWARE और पुराने MIDDLEWARE_CLASSES दोनों के साथ संगत हो। Django के साथ शामिल सभी मिडलवेयर कक्षाएं दोनों सेटिंग्स के साथ संगत हैं।

__init__() एक __init__() विधि प्रदान करता है जो एक वैकल्पिक get_response तर्क स्वीकार करता है और इसे get_response में संग्रहीत करता है।

__call__() विधि:

  1. self.process_request(request) कॉल करें self.process_request(request) (यदि परिभाषित किया गया है)।
  2. बाद में मिडलवेयर और दृश्य से प्रतिक्रिया प्राप्त करने के लिए self.get_response(request) को कॉल करता है।
  3. self.process_response(request, response) कॉल करें self.process_response(request, response) (यदि परिभाषित किया गया है)।
  4. प्रतिक्रिया देता है।

यदि MIDDLEWARE_CLASSES साथ उपयोग किया जाता है, तो MIDDLEWARE_CLASSES __call__() विधि का उपयोग कभी नहीं किया जाएगा; Django सीधे process_request() और process_response() कहता है।

ज्यादातर मामलों में, इस मिक्सिन से विरासत में एक पुरानी शैली के मिडलवेयर को नए सिस्टम के साथ पर्याप्त बैकवर्ड-संगतता के साथ बनाने के लिए पर्याप्त होगा। नया शॉर्ट-सर्कुलेटिंग सेमेंटिक्स मौजूदा मिडलवेयर के लिए हानिरहित या फायदेमंद होगा। कुछ मामलों में, एक मिडलवेयर क्लास को नए शब्दार्थों को समायोजित करने के लिए कुछ परिवर्तनों की आवश्यकता हो सकती है।

MIDDLEWARE और MIDDLEWARE_CLASSES का उपयोग करने के बीच ये व्यवहारगत अंतर हैं:

  1. MIDDLEWARE_CLASSES तहत, प्रत्येक मिडलवेयर के पास हमेशा अपनी process_response विधि होगी, भले ही पहले वाली मिडलवेयर ने अपने process_request पद्धति से प्रतिक्रिया देकर वापसी की हो। MIDDLEWARE तहत, मिडलवेयर एक प्याज की तरह अधिक व्यवहार करता है: जिस परत पर प्रतिक्रिया होती है, वह उसी तरह की परतें होती हैं, जो रास्ते में अनुरोध को देखती हैं। यदि एक मिडलवेयर शॉर्ट-सर्किट, केवल वह मिडलवेयर और उससे पहले वाले। MIDDLEWARE की प्रतिक्रिया देखेंगे।
  2. MIDDLEWARE_CLASSES तहत, process_exception एक मिडलवेयर process_request पद्धति से उठाए गए अपवादों पर लागू होती है। MIDDLEWARE तहत, process_exception केवल दृश्य से उठाए गए अपवादों पर लागू होती है (या TemplateResponse के render विधि से)। किसी मिडलवेयर से उठाए गए अपवाद को उचित HTTP प्रतिक्रिया में बदल दिया जाता है और फिर अगले मिडलवेयर को भेज दिया जाता है।
  3. MIDDLEWARE_CLASSES तहत, यदि एक process_response विधि एक अपवाद को उठाती है, तो पहले के सभी मिडलवेयर की process_response विधियाँ छोड़ दी जाती हैं और 500 Internal Server Error HTTP प्रतिसाद हमेशा दिया जाता है (भले ही अपवाद बढ़ा हो। उदाहरण के लिए: Http404 )। MIDDLEWARE तहत, मिडलवेयर से उठाया गया एक अपवाद तुरंत उचित HTTP प्रतिक्रिया में बदल जाएगा, और फिर लाइन में अगला मिडलवेयर उस प्रतिक्रिया को देखेगा। मिडलवेयर एक अपवाद को बढ़ाने के कारण मिडिलवेयर को कभी नहीं छोड़ता है।