Django 2.1

Middleware




django

Middleware

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

उपलब्ध मिडलवेयर

कैशे मिडलवेयर

class UpdateCacheMiddleware [source]
class FetchFromCacheMiddleware [source]

साइट-वाइड कैश सक्षम करें। यदि ये सक्षम हैं, तो प्रत्येक CACHE_MIDDLEWARE_SECONDS संचालित पृष्ठ को CACHE_MIDDLEWARE_SECONDS सेटिंग को परिभाषित करने के लिए लंबे समय तक कैश किया जाएगा। कैश डॉक्यूमेंटेशन देखें।

"आम" मिडलवेयर

class CommonMiddleware [source]

पूर्णतावादियों के लिए कुछ उपयुक्तता जोड़ता है:

  • DISALLOWED_USER_AGENTS सेटिंग में उपयोगकर्ता एजेंटों के लिए DISALLOWED_USER_AGENTS , जो संकलित नियमित अभिव्यक्ति वस्तुओं की एक सूची होनी चाहिए।
  • APPEND_SLASH और PREPEND_WWW सेटिंग्स के आधार पर URL पुनर्लेखन करता है।

    यदि APPEND_SLASH True और प्रारंभिक URL एक स्लैश के साथ समाप्त नहीं होता है, और यह URLconf में नहीं पाया जाता है, तो अंत में एक स्लैश जोड़कर एक नया URL बनता है। यदि यह नया URL URLconf में मिलता है, तो Django इस नए URL के अनुरोध को पुनर्निर्देशित करता है। अन्यथा, प्रारंभिक URL हमेशा की तरह संसाधित होता है।

    उदाहरण के लिए, foo.com/bar को foo.com/bar/ पुनर्निर्देशित किया जाएगा यदि आपके पास foo.com/bar लिए एक मान्य URL पैटर्न नहीं है, लेकिन foo.com/bar लिए एक मान्य पैटर्न है।

    यदि PREPEND_WWW True , तो PREPEND_WWW URL में "www" की कमी है, उन्हें एक अग्रणी URL पर "www।"

    ये दोनों विकल्प URL को सामान्य करने के लिए हैं। दर्शन यह है कि प्रत्येक URL में एक, और केवल एक, स्थान होना चाहिए। तकनीकी रूप से एक URL foo.com/bar से अलग है - एक खोज-इंजन अनुक्रमणिका उन्हें अलग URL के रूप में मानेगी - इसलिए URL को सामान्य बनाने के लिए यह सबसे अच्छा अभ्यास है।

  • गैर-स्ट्रीमिंग प्रतिक्रियाओं के लिए Content-Length शीर्ष लेख सेट करता है।
CommonMiddleware.response_redirect_class

HttpResponsePermanentRedirect को डिफ़ॉल्ट। Subclass CommonMiddleware और मिडलवेयर द्वारा जारी रीडायरेक्ट को कस्टमाइज़ करने के लिए विशेषता को ओवरराइड करता है।

class BrokenLinkEmailsMiddleware [source]

GZip मिडलवेयर

class GZipMiddleware [source]

चेतावनी

सुरक्षा शोधकर्ताओं ने हाल ही में खुलासा किया कि जब किसी वेबसाइट पर संपीड़न तकनीक ( GZipMiddleware सहित) का उपयोग किया जाता है, तो साइट कई संभावित हमलों के संपर्क में आ सकती है। अपनी साइट पर GZipMiddleware का उपयोग करने से पहले, आपको बहुत सावधानी से विचार करना चाहिए कि क्या आप इन हमलों के अधीन हैं। यदि आप किसी भी संदेह में हैं कि क्या आप प्रभावित हैं, तो आपको GZipMiddleware का उपयोग करने से बचना चाहिए। अधिक जानकारी के लिए, BREACH पेपर (PDF) और breachattack.com देखें

GZip संपीड़न (सभी आधुनिक ब्राउज़र) को समझने वाले ब्राउज़रों के लिए सामग्री को संपीड़ित करता है।

इस मिडलवेयर को किसी भी अन्य मिडलवेयर से पहले रखा जाना चाहिए, जो कि रिस्पांस बॉडी को पढ़ने या लिखने की आवश्यकता है ताकि बाद में संपीड़न हो।

यदि निम्न में से कोई भी सत्य है तो यह सामग्री को संपीड़ित नहीं करेगा:

  • कंटेंट बॉडी 200 बाइट्स से कम लंबी है।
  • प्रतिक्रिया ने पहले ही Content-Encoding हेडर सेट कर दिया है।
  • अनुरोध (ब्राउज़र) ने gzip युक्त Accept-Encoding शीर्ष लेख नहीं भेजा है।

यदि प्रतिक्रिया में ETag हेडर है, तो ETFC 7232 # सेक्शन-2.1 के अनुपालन के लिए ETag को कमजोर बना दिया गया है।

आप gzip_page() डेकोरेटर का उपयोग करके व्यक्तिगत विचारों में GZip संपीड़न लागू कर सकते हैं।

सशर्त जीईटी मिडलवेयर

class ConditionalGetMiddleware [source]

सशर्त GET संचालन संभालता है। यदि प्रतिक्रिया में ETag हेडर नहीं है, तो जरूरत पड़ने पर मिडलवेयर एक को जोड़ता है। यदि प्रतिक्रिया में ETag या Last-Modified हेडर है, और अनुरोध में ETag Last-Modified ETag If-None-Match या If-Modified-Since , तो प्रतिक्रिया को HttpResponseNotModified द्वारा प्रतिस्थापित किया जाता है।

लोकेल मिडलवेयर

class LocaleMiddleware [source]

अनुरोध से डेटा के आधार पर भाषा का चयन सक्षम करता है। यह प्रत्येक उपयोगकर्ता के लिए सामग्री को अनुकूलित करता है। अंतर्राष्ट्रीयकरण प्रलेखन देखें।

LocaleMiddleware.response_redirect_class

HttpResponseRedirect को डिफ़ॉल्ट। Subclass LocaleMiddleware और मिडलवेयर द्वारा जारी रीडायरेक्ट को कस्टमाइज़ करने के लिए विशेषता को ओवरराइड करता है।

संदेश मिडिलवेयर

class MessageMiddleware [source]

कुकी- और सत्र-आधारित संदेश समर्थन को सक्षम करता है। संदेश प्रलेखन देखें।

सुरक्षा मिडिलवेयर

चेतावनी

यदि आपकी परिनियोजन स्थिति अनुमति देती है, तो यह आमतौर पर एक अच्छा विचार है कि आपका फ्रंट-एंड वेब सर्वर SecurityMiddleware द्वारा प्रदान की गई कार्यक्षमता का प्रदर्शन करे। इस तरह, अगर ऐसे अनुरोध हैं जो Django (जैसे स्थिर मीडिया या उपयोगकर्ता-अपलोड की गई फ़ाइलों) द्वारा सेवा नहीं किए जाते हैं, तो उनके पास आपके Django एप्लिकेशन के अनुरोधों के समान सुरक्षा होंगे।

class SecurityMiddleware [source]

django.middleware.security.SecurityMiddleware अनुरोध / प्रतिक्रिया चक्र को कई सुरक्षा संवर्द्धन प्रदान करता है। प्रत्येक को एक सेटिंग के साथ स्वतंत्र रूप से सक्षम या अक्षम किया जा सकता है।

HTTP सख्त परिवहन सुरक्षा

उन साइटों के लिए जिन्हें केवल HTTPS से अधिक एक्सेस किया जाना चाहिए, आप "स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी" हेडर सेट करके अपने ब्राउज़र को असुरक्षित कनेक्शन (कुछ समय के लिए) के माध्यम से अपने डोमेन नाम से कनेक्ट करने से मना कर सकते हैं। यह कुछ एसएसएल-स्ट्रिपिंग मैन-इन-द-बीच (MITM) हमलों के लिए आपके जोखिम को कम करता है।

यदि आप SECURE_HSTS_SECONDS सेटिंग को एक गैर-शून्य पूर्णांक मान पर सेट करते हैं, तो SecurityMiddleware आपके लिए यह शीर्षक सभी HTTPS प्रतिक्रियाओं पर सेट करेगा।

HSTS को सक्षम करते समय, परीक्षण के लिए पहले एक छोटे से मूल्य का उपयोग करना एक अच्छा विचार है, उदाहरण के लिए, SECURE_HSTS_SECONDS एक घंटे के लिए। जब भी कोई वेब ब्राउज़र आपकी साइट से HSTS हैडर को देखता है, तो वह दी गई अवधि के लिए आपके डोमेन के साथ गैर-सुरक्षित रूप से (HTTP का उपयोग करके) संवाद करने से इंकार कर देगा। एक बार जब आप पुष्टि कर लेते हैं कि आपकी साइट पर सभी संपत्तियाँ सुरक्षित रूप से दी गई हैं (अर्थात HSTS ने कुछ भी नहीं तोड़ा है), तो इस मूल्य को बढ़ाना एक अच्छा विचार है, ताकि निराधार आगंतुकों को संरक्षित किया जाएगा (31536000 सेकंड, अर्थात 1 वर्ष, सामान्य है)।

इसके अतिरिक्त, यदि आप SECURE_HSTS_INCLUDE_SUBDOMAINS सेटिंग को True सेट करते हैं, तो SecurityMiddleware , includeSubDomains निर्देश को Strict-Transport-Security शीर्ष लेख में जोड़ देगा। यह अनुशंसा की जाती है (यह मानते हुए कि सभी उप-डोमेन को विशेष रूप से HTTPS का उपयोग करके परोसा जाता है), अन्यथा आपकी साइट अभी भी एक उप-डोमेन के असुरक्षित कनेक्शन के माध्यम से असुरक्षित हो सकती है।

यदि आप अपनी साइट को ब्राउज़र प्रीलोड सूची में सबमिट करना चाहते हैं, तो SECURE_HSTS_PRELOAD को True सेट करें। यह Strict-Transport-Security हेडर के लिए preload निर्देश को जोड़ता है।

चेतावनी

HSTS नीति आपके संपूर्ण डोमेन पर लागू होती है, न कि केवल उस प्रतिक्रिया का URL जो आप हेडर सेट करते हैं। इसलिए, आपको केवल इसका उपयोग करना चाहिए यदि आपका संपूर्ण डोमेन केवल HTTPS के माध्यम से परोसा जाता है।

HSTS हेडर का उचित रूप से सम्मान करने वाले ब्राउज़र उपयोगकर्ताओं को चेतावनी को बायपास करने और समाप्त हो चुकी, स्व-हस्ताक्षरित या अन्यथा अमान्य SSL प्रमाणपत्र वाली साइट से कनेक्ट करने की अनुमति देने से इनकार कर देंगे। यदि आप HSTS का उपयोग करते हैं, तो सुनिश्चित करें कि आपके प्रमाणपत्र अच्छे आकार में हैं और इस तरह से बने रहें!

ध्यान दें

यदि आपको लोड-बैलेंसर या रिवर्स-प्रॉक्सी सर्वर के पीछे तैनात किया गया है, और Strict-Transport-Security हेडर को आपकी प्रतिक्रियाओं में नहीं जोड़ा जा रहा है, तो ऐसा इसलिए हो सकता है क्योंकि Django को यह एहसास नहीं है कि यह एक सुरक्षित कनेक्शन पर है; आपको SECURE_PROXY_SSL_HEADER सेटिंग सेट करने की आवश्यकता हो सकती है।

X-Content-Type-Options: nosniff

कुछ ब्राउज़र Content-Type हेडर को ओवरराइड करते हुए, उनके द्वारा प्राप्त की गई संपत्ति के प्रकारों का अनुमान लगाने का प्रयास करेंगे। हालांकि यह साइटों को अनुचित रूप से कॉन्फ़िगर किए गए सर्वरों के साथ प्रदर्शित करने में मदद कर सकता है, यह एक सुरक्षा जोखिम भी पैदा कर सकता है।

यदि आपकी साइट उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों की सेवा करती है, तो एक दुर्भावनापूर्ण उपयोगकर्ता एक विशेष रूप से तैयार की गई फ़ाइल अपलोड कर सकता है जिसे ब्राउज़र द्वारा HTML या जावास्क्रिप्ट के रूप में व्याख्या किया जाएगा जब आप इसे कुछ हानिरहित होने की उम्मीद करते हैं।

ब्राउज़र को सामग्री प्रकार का अनुमान लगाने से रोकने के लिए और उसे हमेशा Content-Type हेडर में दिए गए प्रकार का उपयोग करने के लिए मजबूर करने के लिए, आप X-Content-Type-Options: nosniff हैडर पास कर सकते हैं। यदि SECURE_CONTENT_TYPE_NOSNIFF सेटिंग True है, तो SecurityMiddleware प्रतिक्रिया सभी प्रतिक्रियाओं के लिए ऐसा करेगी।

ध्यान दें कि ज्यादातर तैनाती स्थितियों में जहां Django उपयोगकर्ता-अपलोड की गई फ़ाइलों की सेवा में शामिल नहीं है, यह सेटिंग आपकी मदद नहीं करेगी। उदाहरण के लिए, यदि आपका MEDIA_URL आपके फ्रंट-एंड वेब सर्वर (nginx, Apache, आदि) द्वारा सीधे परोसा जाता है, तो आप इस हेडर को वहां सेट करना चाहेंगे। दूसरी ओर, यदि आप फ़ाइलों को डाउनलोड करने के लिए प्राधिकरण की तरह कुछ करने के लिए Django का उपयोग कर रहे हैं और आप अपने वेब सर्वर का उपयोग करके हेडर सेट नहीं कर सकते हैं, तो यह सेटिंग उपयोगी होगी।

X-XSS-Protection: 1; mode=block

कुछ ब्राउज़रों में ऐसी सामग्री को ब्लॉक करने की क्षमता होती है जो XSS हमले के रूप में प्रकट होती है। वे किसी पृष्ठ के GET या POST मापदंडों में जावास्क्रिप्ट सामग्री की तलाश करके काम करते हैं। यदि सर्वर की प्रतिक्रिया में जावास्क्रिप्ट फिर से आ जाती है, तो पेज को रेंडरिंग से ब्लॉक कर दिया जाता है और इसके बजाय एक एरर पेज दिखाया जाता है।

एक्सएसएस-एक्सएसएस-प्रोटेक्शन हेडर का उपयोग एक्सएसएस फिल्टर के संचालन को नियंत्रित करने के लिए किया जाता है।

ब्राउज़र में XSS फ़िल्टर को सक्षम करने के लिए, और इसे हमेशा के लिए संदिग्ध XSS हमलों को रोकने के लिए मजबूर करें, आप X-XSS-Protection: 1; mode=block पास कर सकते हैं X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; mode=block हेडर। यदि SECURE_BROWSER_XSS_FILTER सेटिंग True है, तो SecurityMiddleware सभी प्रतिक्रियाओं के लिए ऐसा करेगा।

चेतावनी

ब्राउज़र XSS फ़िल्टर एक उपयोगी रक्षा उपाय है, लेकिन इसे विशेष रूप से निर्भर नहीं होना चाहिए। यह सभी XSS हमलों का पता नहीं लगा सकता है और सभी ब्राउज़र हेडर का समर्थन नहीं करते हैं। सुनिश्चित करें कि आप अभी भी XSS हमलों को रोकने के लिए सभी इनपुट को मान्य और सैनिटाइज़ कर रहे हैं।

एसएसएल रीडायरेक्ट

यदि आपकी साइट HTTP और HTTPS कनेक्शन प्रदान करती है, तो अधिकांश उपयोगकर्ता डिफ़ॉल्ट रूप से असुरक्षित कनेक्शन के साथ समाप्त हो जाएंगे। सर्वोत्तम सुरक्षा के लिए, आपको सभी HTTP कनेक्शन को HTTPS पर पुनर्निर्देशित करना चाहिए।

यदि आप SECURE_SSL_REDIRECT सेटिंग को सही पर सेट करते हैं, तो SecurityMiddleware स्थायी रूप से (HTTP 301) सभी HTTP कनेक्शन को HTTPS पर रीडायरेक्ट करेगा।

ध्यान दें

प्रदर्शन कारणों से, यह Django के बाहर इन रीडायरेक्ट को करने के लिए बेहतर है, फ्रंट-एंड लोड बैलेंसर या रिवर्स-प्रॉक्सी सर्वर जैसे कि नगनेक्स SECURE_SSL_REDIRECT परिनियोजन स्थितियों के लिए अभिप्रेत है जहाँ यह विकल्प नहीं है।

यदि SECURE_SSL_HOST सेटिंग का मान है, तो सभी रीडायरेक्ट मूल रूप से अनुरोधित होस्ट के बजाय उस होस्ट को भेजे जाएंगे।

यदि आपकी साइट पर कुछ पृष्ठ हैं जो HTTP पर उपलब्ध होने चाहिए, और HTTPS पर पुनर्निर्देशित नहीं किए जाते हैं, तो आप SECURE_REDIRECT_EXEMPT सेटिंग में उन URL से मिलान करने के लिए नियमित अभिव्यक्ति सूचीबद्ध कर सकते हैं।

ध्यान दें

यदि आप लोड-बैलेंसर या रिवर्स-प्रॉक्सी सर्वर के पीछे तैनात हैं और Django नहीं बता सकता है कि वास्तव में अनुरोध पहले से ही सुरक्षित है, तो आपको SECURE_PROXY_SSL_HEADER सेटिंग सेट करने की आवश्यकता हो सकती है।

सत्र मिडलवेयर

class SessionMiddleware [source]

सत्र समर्थन सक्षम करता है। सत्र प्रलेखन देखें।

साइट के मिडिलवेयर

class CurrentSiteMiddleware [source]

हर आने वाली HttpRequest ऑब्जेक्ट के लिए वर्तमान साइट का प्रतिनिधित्व करने वाली site विशेषता जोड़ता है। साइटों के दस्तावेज़ देखें।

प्रमाणीकरण मिडिलवेयर

class AuthenticationMiddleware

user विशेषता को जोड़ता है, वर्तमान में लॉग-इन उपयोगकर्ता का प्रतिनिधित्व करते हुए, आने वाली HttpRequest ऑब्जेक्ट के लिए। वेब अनुरोधों में प्रमाणीकरण देखें।

class RemoteUserMiddleware

वेब सर्वर के उपयोग के लिए मिडिलवेयर ने प्रमाणीकरण प्रदान किया। उपयोग विवरण के लिए REMOTE_USER का उपयोग करके प्रमाणीकरण देखें।

class PersistentRemoteUserMiddleware

वेब सर्वर के उपयोग के लिए मिडिलवेयर ने केवल लॉगिन पृष्ठ पर सक्षम होने पर प्रमाणीकरण प्रदान किया। केवल उपयोग विवरण के लिए लॉगिन पृष्ठों पर REMOTE_USER का उपयोग करना देखें।

CSRF सुरक्षा मिडिलवेयर

class CsrfViewMiddleware [source]

क्रॉस साइट रिक्वेस्ट फोर्सेस के खिलाफ POST फॉर्म में छिपे हुए फॉर्म फील्ड्स को जोड़कर और सही वैल्यू के लिए रिक्वेस्ट को चेक करने के लिए सुरक्षा जोड़ता है। क्रॉस साइट अनुरोध फोर्जरी संरक्षण प्रलेखन देखें

X-Frame-Options मिडलवेयर

class XFrameOptionsMiddleware [source]

एक्स-फ्रेम-ऑप्शन हैडर के माध्यम से सरल क्लिकजैकिंग सुरक्षा

मिडलवेयर ऑर्डर कर रहा है

यहाँ विभिन्न Django मिडलवेयर वर्गों के आदेश के बारे में कुछ संकेत दिए गए हैं:

  1. SecurityMiddleware

    यदि आप SSL रीडायरेक्ट को चालू करने जा रहे हैं, तो इसे सूची के शीर्ष के पास जाना चाहिए, क्योंकि यह अन्य अनावश्यक मिडलवेयर के झुंड के माध्यम से चलने से बचता है।

  2. UpdateCacheMiddleware

    इससे पहले कि आप Vary हेडर ( SessionMiddleware , GZipMiddleware , LocaleMiddleware ) को संशोधित करें।

  3. GZipMiddleware

    किसी भी मिडलवेयर से पहले जो प्रतिक्रिया निकाय को बदल या उपयोग कर सकता है।

    UpdateCacheMiddleware बाद: Vary हेडर को संशोधित करता है।

  4. SessionMiddleware

    UpdateCacheMiddleware बाद: Vary हेडर को संशोधित करता है।

  5. ConditionalGetMiddleware

    किसी भी मिडलवेयर से पहले जो प्रतिक्रिया को बदल सकता है (यह ETag हेडर सेट करता है)।

    GZipMiddleware बाद तो यह gzipped सामग्री पर ETag हेडर की गणना नहीं करेगा।

  6. LocaleMiddleware

    SessionMiddleware (सत्र डेटा का उपयोग करता है) और UpdateCacheMiddleware ( Vary हेडर को संशोधित करता है) के बाद सबसे ऊपर से एक।

  7. CommonMiddleware

    किसी भी मिडलवेयर से पहले जो प्रतिक्रिया को बदल सकता है (यह Content-Length हेडर सेट करता है)। एक मिडलवेयर जो CommonMiddleware से पहले दिखाई देता है और प्रतिक्रिया को बदलता है, Content-Length रीसेट करना चाहिए।

    शीर्ष पर बंद करें: यह तब रीडायरेक्ट करता है जब APPEND_SLASH या PREPEND_WWW True सेट हो।

  8. CsrfViewMiddleware

    किसी भी दृश्य से पहले मिडलवेयर मानता है कि CSRF के हमलों से निपटा गया है।

    यदि आप CSRF_USE_SESSIONS का उपयोग कर रहे हैं तो यह SessionMiddleware बाद आना चाहिए।

  9. AuthenticationMiddleware

    SessionMiddleware बाद: सत्र भंडारण का उपयोग करता है।

  10. MessageMiddleware

    SessionMiddleware बाद: सत्र-आधारित भंडारण का उपयोग कर सकते हैं।

  11. FetchFromCacheMiddleware

    किसी भी मिडलवेयर के बाद जो Vary हेडर को संशोधित करता है: उस हेडर का उपयोग कैश हैश-की के लिए मान लेने के लिए किया जाता है।

  12. FlatpageFallbackMiddleware

    नीचे के पास होना चाहिए क्योंकि यह मिडलवेयर का अंतिम उपाय है।

  13. RedirectFallbackMiddleware

    नीचे के पास होना चाहिए क्योंकि यह मिडलवेयर का अंतिम उपाय है।