Settings

• कोर सेटिंग्स
• Auth
• Messages
• Sessions
• Sites
• स्थैतिक फ़ाइलें
• कोर सेटिंग्स सामयिक सूचकांक

कोर सेटिंग्स

यहाँ Django कोर में उपलब्ध सेटिंग्स और उनके डिफ़ॉल्ट मानों की एक सूची दी गई है। कंट्रिब ऐप्स द्वारा प्रदान की गई सेटिंग्स नीचे सूचीबद्ध हैं, इसके बाद कोर सेटिंग्स का एक सामयिक सूचकांक है। परिचयात्मक सामग्री के लिए, सेटिंग विषय मार्गदर्शिका देखें ।

ABSOLUTE_URL_OVERRIDES

डिफ़ॉल्ट: {} (खाली शब्दकोश)

एक शब्दकोश मानचित्र "app_label.model_name" एक मॉडल ऑब्जेक्ट लेने और अपने URL को वापस करने वाले कार्यों के लिए तार। यह प्रति-स्थापना के आधार पर get_absolute_url() विधियों को सम्मिलित करने या ओवरराइड करने का एक तरीका है। उदाहरण:

ABSOLUTE_URL_OVERRIDES = {
    'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
    'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

ध्यान दें कि इस सेटिंग में उपयोग किया जाने वाला मॉडल का नाम वास्तविक मॉडल वर्ग के नाम की परवाह किए बिना सभी निम्न-केस होना चाहिए।

ADMINS

डिफ़ॉल्ट: [] (खाली सूची)

उन सभी लोगों की सूची जो कोड त्रुटि सूचनाएँ प्राप्त करते हैं। जब DEBUG=False और AdminEmailHandler को AdminEmailHandler (डिफ़ॉल्ट रूप से किया गया) में कॉन्फ़िगर किया गया है, तो Django इन लोगों को अनुरोध / प्रतिक्रिया चक्र में उठाए गए अपवादों का विवरण ईमेल करता है।

सूची में प्रत्येक आइटम (पूर्ण नाम, ईमेल पता) का एक टपल होना चाहिए। उदाहरण:

[('John', '[email protected]'), ('Mary', '[email protected]')]

ALLOWED_HOSTS

डिफ़ॉल्ट: [] (खाली सूची)

होस्ट / डोमेन नामों का प्रतिनिधित्व करने वाले स्ट्रिंग्स की एक सूची जो इस Django साइट की सेवा कर सकती है। यह HTTP होस्ट हेडर हमलों को रोकने के लिए एक सुरक्षा उपाय है, जो कई प्रतीत होने वाले सुरक्षित वेब सर्वर कॉन्फ़िगरेशन के तहत भी संभव है।

इस सूची में मान पूरी तरह से योग्य नाम हो सकते हैं (उदाहरण के लिए 'www.example.com' ), जिस स्थिति में उन्हें अनुरोध के Host हेडर के विरुद्ध मिलान किया जाएगा (केस-असंवेदनशील, पोर्ट सहित नहीं)। एक अवधि के साथ शुरू होने वाले मूल्य को एक उपडोमेन वाइल्डकार्ड के रूप में इस्तेमाल किया जा सकता है: '.example.com' example.com , www.example.com और example.com किसी अन्य उपडोमेन से मेल खाएगा। '*' का मान किसी भी चीज़ से मेल खाएगा; इस मामले में आप Host हेडर की अपनी मान्यता प्रदान करने के लिए जिम्मेदार हैं (शायद एक मिडलवेयर में; यदि ऐसा है तो मिडलवेयर को पहले MIDDLEWARE में सूचीबद्ध किया जाना चाहिए)।

Django किसी भी प्रविष्टियों की पूरी तरह से योग्य डोमेन नाम (FQDN) की अनुमति देता है। कुछ ब्राउज़रों में Host हेडर में एक अनुगामी बिंदु शामिल होता है जिसे होस्ट सत्यापन करते समय Django स्ट्रिप्स करता है।

यदि Host शीर्ष लेख (या USE_X_FORWARDED_HOST X-Forwarded-Host यदि USE_X_FORWARDED_HOST सक्षम है) तो इस सूची में किसी भी मान से मेल नहीं खाता है, django.http.HttpRequest.get_host() विधि SuspiciousOperation बढ़ा देगा।

जब DEBUG=False True और ALLOWED_HOSTS खाली है, तो होस्ट को ['localhost', '127.0.0.1', '[::1]'] खिलाफ मान्य किया गया है।

परीक्षण चलाते समय ALLOWED_HOSTS की भी जाँच की जाती है ।

यह सत्यापन केवल django.http.HttpRequest.get_host() माध्यम से लागू होता है django.http.HttpRequest.get_host() ; यदि आपका कोड सीधे request.META से Host हेडर तक पहुंचता है। तो आप इस सुरक्षा संरक्षण को दरकिनार कर रहे हैं।

APPEND_SLASH

डिफ़ॉल्ट: True

True सेट होने पर, यदि अनुरोध URL URLconf के किसी भी पैटर्न से मेल नहीं खाता है और यह स्लैश में समाप्त नहीं होता है, तो HTTP रीडायरेक्ट को उसी URL में स्लैश के साथ जारी किया जाता है। ध्यान दें कि रीडायरेक्ट किसी भी डेटा खो जाने के कारण POST अनुरोध में प्रस्तुत किया जा सकता है।

APPEND_SLASH सेटिंग का उपयोग केवल तभी किया जाता है जब CommonMiddleware स्थापित किया गया है ( Middleware देखें)। PREPEND_WWW भी देखें।

CACHES

चूक:

{
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    }
}

एक शब्दकोश जिसमें Django के साथ उपयोग किए जाने वाले सभी कैश के लिए सेटिंग है। यह एक नेस्टेड डिक्शनरी है, जिसकी सामग्री कैशे उपनामों को एक शब्दकोश में कैपेक्स करती है, जिसमें एक व्यक्ति कैशे के विकल्प होते हैं।

CACHES सेटिंग को default कैश को कॉन्फ़िगर करना होगा; अतिरिक्त कैश की संख्या भी निर्दिष्ट की जा सकती है। यदि आप स्थानीय मेमोरी कैश के अलावा कैश बैकेंड का उपयोग कर रहे हैं, या आपको कई कैश को परिभाषित करने की आवश्यकता है, तो अन्य विकल्पों की आवश्यकता होगी। निम्नलिखित कैश विकल्प उपलब्ध हैं।

BACKEND

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

कैश का उपयोग करने का समर्थन करता है। अंतर्निहित कैश बैकेंड हैं:

• 'django.core.cache.backends.db.DatabaseCache'
• 'django.core.cache.backends.dummy.DummyCache'
• 'django.core.cache.backends.filebased.FileBasedCache'
• 'django.core.cache.backends.locmem.LocMemCache'
• 'django.core.cache.backends.memcached.MemcachedCache'
• 'django.core.cache.backends.memcached.PyLibMCCache'

आप एक कैश बैकएंड का उपयोग कर सकते हैं जो कैश बैकएंड क्लास (यानी mypackage.backends.whatever.WhateverCache ) के पूरी तरह से योग्य पथ पर सेट करके Django के साथ जहाज नहीं करता है।

KEY_FUNCTION

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

def make_key(key, key_prefix, version):
    return ':'.join([key_prefix, str(version), key])

आप किसी भी महत्वपूर्ण फ़ंक्शन का उपयोग कर सकते हैं, जब तक कि इसमें एक ही तर्क हस्ताक्षर हो।

अधिक जानकारी के लिए कैश दस्तावेज़ देखें।

KEY_PREFIX

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

Django सर्वर द्वारा उपयोग की जाने वाली सभी कैश कुंजियों में एक स्ट्रिंग जो स्वचालित रूप से शामिल होगी (डिफ़ॉल्ट रूप से पूर्व-निर्धारित)।

अधिक जानकारी के लिए कैश दस्तावेज़ देखें।

LOCATION

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

उपयोग करने के लिए कैश का स्थान। यह फ़ाइल सिस्टम कैश के लिए निर्देशिका, मेकैच सर्वर के लिए एक होस्ट और पोर्ट या स्थानीय मेमोरी कैश के लिए केवल एक पहचान नाम हो सकता है। उदाहरण के लिए:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}

OPTIONS

डिफ़ॉल्ट: None

कैश बैकएंड को पास करने के लिए अतिरिक्त पैरामीटर। उपलब्ध पैरामीटर आपके कैश बैकएंड के आधार पर भिन्न होते हैं।

उपलब्ध मापदंडों की कुछ जानकारी कैशे तर्क दस्तावेज में पाई जा सकती है। अधिक जानकारी के लिए, अपने बैकएंड मॉड्यूल के स्वयं के प्रलेखन से परामर्श करें।

TIMEOUT

डिफ़ॉल्ट: 300

कैश प्रविष्टि से पहले सेकंड की संख्या को बासी माना जाता है। यदि इस सेटिंग का मान None , तो कैश प्रविष्टियां समाप्त नहीं होंगी।

VERSION

डिफ़ॉल्ट: 1

Django सर्वर द्वारा उत्पन्न कैश कीज़ के लिए डिफ़ॉल्ट संस्करण संख्या।

अधिक जानकारी के लिए कैश दस्तावेज़ देखें।

CACHE_MIDDLEWARE_ALIAS

डिफ़ॉल्ट: default

कैश कनेक्शन के लिए कैश मिडवेअर का उपयोग करें।

CACHE_MIDDLEWARE_KEY_PREFIX

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

एक स्ट्रिंग जो कैश मिडलवेयर द्वारा उत्पन्न कैश कुंजियों के लिए उपसर्ग होगी। यह उपसर्ग KEY_PREFIX सेटिंग के साथ संयुक्त है; यह इसे प्रतिस्थापित नहीं करता है।

Django के कैश ढांचे को देखें।

CACHE_MIDDLEWARE_SECONDS

डिफ़ॉल्ट: 600

कैश मिडलवेयर के लिए पृष्ठ को कैश करने के लिए सेकंड की डिफ़ॉल्ट संख्या।

Django के कैश ढांचे को देखें।

CSRF_COOKIE_AGE

डिफ़ॉल्ट: 31449600 (लगभग 1 वर्ष, सेकंड में)

CSRF कुकीज़ की आयु, सेकंड में।

उपयोगकर्ता द्वारा किसी ब्राउज़र को बंद करने या किसी पृष्ठ को बुकमार्क करने और फिर उस पृष्ठ को ब्राउज़र कैश से लोड करने की स्थिति में लंबे समय तक रहने की समय सीमा निर्धारित करने का कारण है। लगातार कुकीज़ के बिना, फ़ॉर्म जमा करना इस मामले में विफल होगा।

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

CSRF_COOKIE_DOMAIN

डिफ़ॉल्ट: None

CSRF कुकी सेट करते समय उपयोग किया जाने वाला डोमेन। यह क्रॉस-सबडोमेन अनुरोधों को आसानी से अनुमति देने के लिए उपयोगी हो सकता है जिन्हें सामान्य क्रॉस साइट अनुरोध जालसाजी संरक्षण से बाहर रखा जा सकता है। इसे "example.com" जैसे एक स्ट्रिंग पर सेट किया जाना चाहिए ताकि एक उप-डोमेन से किसी फ़ॉर्म से POST अनुरोध को किसी अन्य उपडोमेन से प्राप्त दृश्य द्वारा स्वीकार किया जा सके।

कृपया ध्यान दें कि इस सेटिंग की उपस्थिति का मतलब यह नहीं है कि Django की CSRF सुरक्षा डिफ़ॉल्ट रूप से क्रॉस-सबडोमेन हमलों से सुरक्षित है - कृपया CSRF सीमाएं अनुभाग देखें।

CSRF_COOKIE_HTTPONLY

डिफ़ॉल्ट: False

CSRF कुकी पर HttpOnly ध्वज का उपयोग करना है या नहीं। यदि यह सही पर सेट है, तो क्लाइंट-साइड जावास्क्रिप्ट CSRF कुकी को एक्सेस करने में सक्षम नहीं होगा।

CSRF कुकी को HttpOnly रूप में नामित करना किसी भी व्यावहारिक सुरक्षा की पेशकश नहीं करता है क्योंकि CSRF केवल क्रॉस-डोमेन हमलों से बचाने के लिए है। यदि कोई हमलावर कुकी को जावास्क्रिप्ट के माध्यम से पढ़ सकता है, तो वे पहले से ही उसी डोमेन पर हैं जहां तक ​​ब्राउज़र जानता है, इसलिए वे वैसे भी कुछ भी कर सकते हैं। (XSS CSRF की तुलना में बहुत बड़ा छेद है।)

हालाँकि सेटिंग थोड़ा व्यावहारिक लाभ प्रदान करती है, लेकिन कभी-कभी सुरक्षा ऑडिटरों द्वारा इसकी आवश्यकता होती है।

यदि आप इसे सक्षम करते हैं और AJAX अनुरोध के साथ CSRF टोकन का मूल्य भेजने की आवश्यकता होती है, तो आपके जावास्क्रिप्ट को कुकी के बजाय पृष्ठ पर एक छिपे हुए CSRF टोकन फॉर्म इनपुट से मूल्य को खींचना होगा।

HttpOnly पर विवरण के लिए SESSION_COOKIE_HTTPONLY देखें।

CSRF_COOKIE_NAME

डिफ़ॉल्ट: 'csrftoken'

CSRF प्रमाणीकरण टोकन के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)। क्रॉस साइट अनुरोध फोर्जरी सुरक्षा देखें।

CSRF_COOKIE_PATH

डिफ़ॉल्ट: '/'

CSRF कुकी पर पथ सेट किया गया। यह या तो आपके Django इंस्टॉलेशन के URL पथ से मेल खाना चाहिए या उस पथ का माता-पिता होना चाहिए।

यदि आपके पास एक ही होस्टनाम के तहत कई Django इंस्टेंसेस चल रहे हैं तो यह उपयोगी है। वे अलग-अलग कुकी पथों का उपयोग कर सकते हैं, और प्रत्येक उदाहरण केवल अपने स्वयं के CSRF कुकी को देखेंगे।

CSRF_COOKIE_SAMESITE

डिफ़ॉल्ट: 'Lax'

CSRF कुकी पर SameSite ध्वज का मूल्य। यह ध्वज कुकी को क्रॉस-साइट अनुरोधों में भेजे जाने से रोकता है।

समान के बारे में विवरण के लिए SESSION_COOKIE_SAMESITE देखें।

CSRF_COOKIE_SECURE

डिफ़ॉल्ट: False

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

CSRF_USE_SESSIONS

डिफ़ॉल्ट: False

एक कुकी के बजाय उपयोगकर्ता के सत्र में CSRF टोकन स्टोर करना है या नहीं। इसके लिए django.contrib.sessions के उपयोग की django.contrib.sessions ।

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

CSRF_FAILURE_VIEW

डिफ़ॉल्ट: 'django.views.csrf.csrf_failure'

CSRF सुरक्षा द्वारा आने वाले अनुरोध को अस्वीकार किए जाने पर दृश्य फ़ंक्शन के लिए एक बिंदीदार पथ का उपयोग किया जाता है। फ़ंक्शन में यह हस्ताक्षर होना चाहिए:

def csrf_failure(request, reason=""):
    ...

जहां reason एक छोटा संदेश है (डेवलपर्स या लॉगिंग के लिए, अंत उपयोगकर्ताओं के लिए नहीं) अनुरोध को अस्वीकार करने का कारण दर्शाता है। इसे एक HttpResponseForbidden को वापस करना चाहिए।

django.views.csrf.csrf_failure() '403_csrf.html' चूक करने वाले एक अतिरिक्त template_name पैरामीटर को स्वीकार करता है। यदि उस नाम का कोई टेम्प्लेट मौजूद है, तो इसका उपयोग पृष्ठ को रेंडर करने के लिए किया जाएगा।

CSRF_HEADER_NAME

डिफ़ॉल्ट: 'HTTP_X_CSRFTOKEN'

CSRF प्रमाणीकरण के लिए उपयोग किए जाने वाले अनुरोध शीर्षलेख का नाम।

अन्य HTTP हेडर के साथ request.META , सर्वर से प्राप्त हेडर नाम को सभी वर्णों को अपरकेस में परिवर्तित करके सामान्य किया जाता है, किसी भी हाइफ़न को अंडरस्कोर के साथ बदल दिया जाता है, और नाम में एक 'HTTP_' उपसर्ग जोड़ दिया जाता है। उदाहरण के लिए, यदि आपका क्लाइंट 'X-XSRF-TOKEN' हेडर भेजता है, तो सेटिंग 'HTTP_X_XSRF_TOKEN' होनी चाहिए।

CSRF_TRUSTED_ORIGINS

डिफ़ॉल्ट: [] (खाली सूची)

होस्ट की एक सूची जो असुरक्षित अनुरोधों (जैसे POST ) के लिए विश्वसनीय उत्पत्ति है। एक secure असुरक्षित अनुरोध के लिए, Django के CSRF सुरक्षा के लिए अनुरोध करना आवश्यक है कि एक Referer शीर्षलेख है जो Host हेडर में मौजूद मूल से मेल खाता है। यह रोकता है, उदाहरण के लिए, api.example.com खिलाफ सफल होने से subdomain.example.com POST अनुरोध। यदि आपको उदाहरण के लिए, HTTPS पर क्रॉस-ओरिजनल असुरक्षित अनुरोधों की आवश्यकता है, तो इस सूची में "subdomain.example.com" जोड़ें। सेटिंग उप-डोमेन का भी समर्थन करती है, इसलिए आप ".example.com" को जोड़ सकते हैं, उदाहरण के लिए, example.com सभी उप-डोमेन से पहुँच की अनुमति देने के लिए।

DATABASES

डिफ़ॉल्ट: {} (खाली शब्दकोश)

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

DATABASES सेटिंग को default डेटाबेस को कॉन्फ़िगर करना होगा; अतिरिक्त डेटाबेसों की संख्या भी निर्दिष्ट की जा सकती है।

सबसे सरल संभव सेटिंग्स फ़ाइल SQLite का उपयोग करके एकल-डेटाबेस सेटअप के लिए है। इसे निम्नलिखित का उपयोग करके कॉन्फ़िगर किया जा सकता है:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'mydatabase',
    }
}

जब अन्य डेटाबेस बैकएंड से कनेक्ट होता है, जैसे कि MySQL, Oracle, या PostgreSQL, अतिरिक्त कनेक्शन पैरामीटर की आवश्यकता होगी। अन्य डेटाबेस प्रकारों को निर्दिष्ट करने के तरीके के बारे में नीचे दी गई ENGINE सेटिंग देखें। यह उदाहरण PostgreSQL के लिए है:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydatabase',
        'USER': 'mydatabaseuser',
        'PASSWORD': 'mypassword',
        'HOST': '127.0.0.1',
        'PORT': '5432',
    }
}

निम्नलिखित आंतरिक विकल्प जो अधिक जटिल कॉन्फ़िगरेशन के लिए आवश्यक हो सकते हैं, वे उपलब्ध हैं:

ATOMIC_REQUESTS

डिफ़ॉल्ट: False

इस डेटाबेस पर लेनदेन में प्रत्येक दृश्य को लपेटने के लिए इसे True पर सेट करें। HTTP अनुरोधों के लिए लेनदेन को देखें।

AUTOCOMMIT

डिफ़ॉल्ट: True

यदि आप Django के लेन-देन प्रबंधन को अक्षम करना चाहते हैं और अपने स्वयं के कार्यान्वयन के लिए इसे False सेट करें।

ENGINE

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

डेटाबेस का उपयोग करने के लिए समर्थन करता है। अंतर्निहित डेटाबेस बैकएंड हैं:

• 'django.db.backends.postgresql'
• 'django.db.backends.mysql'
• 'django.db.backends.sqlite3'
• 'django.db.backends.oracle'

आप एक डेटाबेस बैकएंड का उपयोग कर सकते हैं जो पूरी तरह से योग्य पथ (यानी mypackage.backends.whatever ) में ENGINE स्थापना करके Django के साथ जहाज नहीं करता है।

HOST

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

डेटाबेस से कनेक्ट करते समय कौन सा होस्ट उपयोग करना है। खाली स्ट्रिंग का मतलब है लोकलहोस्ट। SQLite के साथ प्रयोग नहीं किया जाता है।

यदि यह मान फ़ॉरवर्ड स्लैश ( '/' ) से शुरू होता है और आप MySQL का उपयोग कर रहे हैं, तो MySQL निर्दिष्ट सॉकेट में एक यूनिक्स सॉकेट के माध्यम से कनेक्ट हो जाएगा। उदाहरण के लिए:

"HOST": '/var/run/mysql'

यदि आप MySQL का उपयोग कर रहे हैं और यह मान फ़ॉरवर्ड स्लैश से शुरू नहीं होता है, तो यह मान होस्ट माना जाता है।

यदि आप डिफ़ॉल्ट रूप से (खाली HOST ) PostgreSQL का उपयोग कर रहे हैं, तो डेटाबेस से कनेक्शन UNIX डोमेन सॉकेट ( pg_hba.conf में 'स्थानीय' लाइनों) के माध्यम से किया जाता है। यदि आपका UNIX डोमेन सॉकेट मानक स्थान पर नहीं है, तो postgresql.conf से unix_socket_directory के समान मूल्य का उपयोग करें। यदि आप टीसीपी सॉकेट्स के माध्यम से कनेक्ट करना चाहते हैं, तो HOST को 'लोकलहोस्ट' या '127.0.0.1' ('होस्ट' लाइनों को pg_hba.conf में pg_hba.conf )। विंडोज पर, आपको हमेशा HOST को परिभाषित करना चाहिए, क्योंकि UNIX डोमेन सॉकेट उपलब्ध नहीं हैं।

NAME

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

उपयोग करने के लिए डेटाबेस का नाम। SQLite के लिए, यह डेटाबेस फ़ाइल का पूर्ण पथ है। पथ निर्दिष्ट करते समय, हमेशा विंडोज पर, यहां तक ​​कि फॉरवर्ड स्लैश का भी उपयोग करें (जैसे C:/homes/user/mysite/sqlite3.db )।

CONN_MAX_AGE

डिफ़ॉल्ट: 0

डेटाबेस कनेक्शन का जीवनकाल, सेकंड में। प्रत्येक अनुरोध के अंत में डेटाबेस को बंद करने के लिए 0 का उपयोग करें - Django के ऐतिहासिक व्यवहार - और असीमित लगातार कनेक्शन के लिए None ।

OPTIONS

डिफ़ॉल्ट: {} (खाली शब्दकोश)

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

उपलब्ध मापदंडों के बारे में कुछ जानकारी डेटाबेस बैकएंड प्रलेखन में पाई जा सकती है। अधिक जानकारी के लिए, अपने बैकएंड मॉड्यूल के स्वयं के प्रलेखन से परामर्श करें।

PASSWORD

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

डेटाबेस से कनेक्ट होने पर उपयोग करने के लिए पासवर्ड। SQLite के साथ प्रयोग नहीं किया जाता है।

PORT

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

डेटाबेस से कनेक्ट करते समय उपयोग करने के लिए पोर्ट। खाली स्ट्रिंग का मतलब है डिफ़ॉल्ट पोर्ट। SQLite के साथ प्रयोग नहीं किया जाता है।

TIME_ZONE

डिफ़ॉल्ट: None

इस डेटाबेस में संग्रहीत डेटासेटाइम के लिए समय क्षेत्र का प्रतिनिधित्व करने वाला एक स्ट्रिंग (यह मानते हुए कि यह समय क्षेत्र का समर्थन नहीं करता है) या None । DATABASES सेटिंग का यह आंतरिक विकल्प सामान्य TIME_ZONE सेटिंग के समान मानों को स्वीकार करता है।

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

जब USE_TZ True और डेटाबेस टाइम ज़ोन (जैसे SQLite, MySQL, Oracle) का समर्थन नहीं करता है, तो Django स्थानीय समय में डेटासेटाइम को इस विकल्प के अनुसार पढ़ता और लिखता है यदि यह सेट है और UTC में नहीं है।

जब USE_TZ True और डेटाबेस टाइम ज़ोन (जैसे PostgreSQL) का समर्थन करता है, तो यह विकल्प सेट करना एक त्रुटि है।

जब USE_TZ False , तो यह विकल्प सेट करना एक त्रुटि है।

DISABLE_SERVER_SIDE_CURSORS

डिफ़ॉल्ट: False

यदि आप सर्वर-साइड कर्सर के उपयोग को QuerySet.iterator() साथ अक्षम करना चाहते हैं तो इसे True सेट करें। लेन-देन पूलिंग और सर्वर-साइड कर्सर उपयोग के मामले का वर्णन करते हैं।

यह एक PostgreSQL-विशिष्ट सेटिंग है।

USER

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

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

TEST

डिफ़ॉल्ट: {} (खाली शब्दकोश)

परीक्षण डेटाबेस के लिए सेटिंग्स का एक शब्दकोश; परीक्षण डेटाबेस के निर्माण और उपयोग के बारे में अधिक जानकारी के लिए, परीक्षण डेटाबेस देखें।

परीक्षण डेटाबेस कॉन्फ़िगरेशन के साथ एक उदाहरण यहां दिया गया है:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'mydatabaseuser',
        'NAME': 'mydatabase',
        'TEST': {
            'NAME': 'mytestdatabase',
        },
    },
}

TEST शब्दकोश में निम्नलिखित कुंजियाँ उपलब्ध हैं:

CHARSET

डिफ़ॉल्ट: None

चरित्र सेट एन्कोडिंग का उपयोग परीक्षण डेटाबेस बनाने के लिए किया जाता है। इस स्ट्रिंग का मान डेटाबेस के माध्यम से सीधे पारित किया जाता है, इसलिए इसका प्रारूप बैकएंड-विशिष्ट है।

PostgreSQL ( postgresql ) और MySQL ( mysql ) द्वारा समर्थित है।

COLLATION

डिफ़ॉल्ट: None

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

केवल mysql बैकएंड के लिए समर्थित है (विवरण के लिए MySQL देखें)।

DEPENDENCIES

डिफ़ॉल्ट: ['default'] , default अलावा सभी डेटाबेसों के लिए, जिनकी कोई निर्भरता नहीं है।

डेटाबेस का निर्माण-क्रम निर्भरताएँ। विवरण के लिए परीक्षण डेटाबेस के निर्माण क्रम को नियंत्रित करने पर प्रलेखन देखें।

MIRROR

डिफ़ॉल्ट: None

डेटाबेस का उपनाम जो इस डेटाबेस को परीक्षण के दौरान दर्पण होना चाहिए।

यह सेटिंग कई डेटाबेस के प्राथमिक / प्रतिकृति (कुछ डेटाबेस द्वारा मास्टर / दास के रूप में संदर्भित) के परीक्षण के लिए अनुमति देने के लिए मौजूद है। विवरण के लिए परीक्षण प्राथमिक / प्रतिकृति विन्यास पर प्रलेखन देखें।

NAME

डिफ़ॉल्ट: None

परीक्षण सूट चलाते समय उपयोग करने के लिए डेटाबेस का नाम।

यदि डिफ़ॉल्ट मान ( None ) का उपयोग SQLite डेटाबेस इंजन के साथ किया जाता है, तो परीक्षण स्मृति निवासी डेटाबेस का उपयोग करेंगे। अन्य सभी डेटाबेस इंजनों के लिए परीक्षण डेटाबेस 'test_' + DATABASE_NAME नाम का उपयोग करेगा।

परीक्षण डेटाबेस देखें।

SERIALIZE

बूलियन मान नियंत्रित करने के लिए कि क्या डिफ़ॉल्ट परीक्षण धावक डेटाबेस को इन-मेमोरी JSON स्ट्रिंग में रनिंग टेस्ट से पहले अनुक्रमित करता है (यदि आपके पास लेनदेन नहीं है तो परीक्षण के बीच डेटाबेस स्थिति को पुनर्स्थापित करने के लिए उपयोग किया जाता है)। यदि आप serialized_rollback=True साथ कोई परीक्षण कक्षा नहीं रखते हैं, तो आप इसे सृजन समय को गति देने के लिए False पर सेट कर सकते हैं।

TEMPLATE

यह एक PostgreSQL-विशिष्ट सेटिंग है।

template डेटाबेस बनाने के लिए एक template का नाम (जैसे 'template0' )।

CREATE_DB

डिफ़ॉल्ट: True

यह एक Oracle विशिष्ट सेटिंग है।

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

CREATE_USER

डिफ़ॉल्ट: True

यह एक Oracle विशिष्ट सेटिंग है।

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

USER

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

परीक्षण चलाने के दौरान उपयोग किए जाने वाले Oracle डेटाबेस से कनेक्ट करते समय उपयोग करने वाला उपयोगकर्ता नाम। यदि प्रदान नहीं किया गया है, तो Django 'test_' + USER उपयोग करेगा।

PASSWORD

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

ओरेकल डेटाबेस से कनेक्ट करने के लिए उपयोग करने वाला पासवर्ड जो परीक्षण चलाते समय उपयोग किया जाएगा। यदि प्रदान नहीं किया गया है, तो Django एक यादृच्छिक पासवर्ड उत्पन्न करेगा।

TBLSPACE

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

टेबलों के नाम जिनका उपयोग परीक्षण चलाते समय किया जाएगा। यदि प्रदान नहीं किया गया है, तो Django 'test_' + USER उपयोग करेगा।

TBLSPACE_TMP

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

अस्थायी टेबलस्पेस का नाम जिसका उपयोग परीक्षण चलाते समय किया जाएगा। यदि प्रदान नहीं किया गया है, तो Django 'test_' + USER + '_temp' उपयोग करेगा।

DATAFILE

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

TBLSPACE के लिए उपयोग करने के लिए डेटाफ़ाइल का नाम। यदि प्रदान नहीं किया जाता है, तो Django TBLSPACE + '.dbf' उपयोग करेगा।

DATAFILE_TMP

डिफ़ॉल्ट: None

यह एक Oracle विशिष्ट सेटिंग है।

TBLSPACE_TMP के लिए उपयोग करने के लिए डेटाफ़ाइल का नाम। यदि प्रदान नहीं किया जाता है, तो Django TBLSPACE_TMP + '.dbf' उपयोग करेगा।

DATAFILE_MAXSIZE

डिफ़ॉल्ट: '500M'

यह एक Oracle विशिष्ट सेटिंग है।

अधिकतम आकार जिसे DATAFILE को बढ़ने की अनुमति है।

DATAFILE_TMP_MAXSIZE

डिफ़ॉल्ट: '500M'

यह एक Oracle विशिष्ट सेटिंग है।

DATAFILE_TMP के अधिकतम आकार को बढ़ने की अनुमति है।

DATAFILE_SIZE

डिफ़ॉल्ट: '50M'

यह एक Oracle विशिष्ट सेटिंग है।

DATAFILE का प्रारंभिक आकार।

DATAFILE_TMP_SIZE

डिफ़ॉल्ट: '50M'

यह एक Oracle विशिष्ट सेटिंग है।

DATAFILE_TMP का प्रारंभिक आकार।

DATAFILE_EXTSIZE

डिफ़ॉल्ट: '25M'

यह एक Oracle विशिष्ट सेटिंग है।

वह राशि जिसके द्वारा अधिक स्थान की आवश्यकता होने पर डेटाटेर को बढ़ाया जाता है।

DATAFILE_TMP_EXTSIZE

डिफ़ॉल्ट: '25M'

यह एक Oracle विशिष्ट सेटिंग है।

वह राशि जिसके द्वारा अधिक स्थान आवश्यक होने पर DATAFILE_TMP बढ़ाया जाता है।

DATA_UPLOAD_MAX_MEMORY_SIZE

डिफ़ॉल्ट: 2621440 (यानी 2.5 एमबी)।

बाइट्स में अधिकतम आकार जो एक अनुरोध निकाय एक SuspiciousOperation RequestDataTooBig ( RequestDataTooBig ) उठाया जाता है से पहले हो सकता है। request.body तक पहुँचने पर चेक किया जाता है। कोई या request.POST और किसी भी फ़ाइल अपलोड डेटा को छोड़कर कुल अनुरोध आकार के खिलाफ गणना की जाती है। चेक को डिसेबल करने के लिए आप इसे सेट कर सकते हैं। जिन अनुप्रयोगों से असामान्य रूप से बड़े फॉर्म पोस्ट प्राप्त होने की उम्मीद है, उन्हें इस सेटिंग को ट्यून करना चाहिए

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

FILE_UPLOAD_MAX_MEMORY_SIZE भी देखें।

DATA_UPLOAD_MAX_NUMBER_FIELDS

डिफ़ॉल्ट: 1000

एक SuspiciousOperation TooManyFields ( TooManyFields ) से पहले GET या POST के माध्यम से प्राप्त होने वाले अधिकतम मापदंडों को उठाया जा सकता है। चेक को डिसेबल करने के लिए आप इसे सेट कर सकते हैं। जिन अनुप्रयोगों से असामान्य रूप से बड़ी संख्या में फ़ील्ड प्राप्त करने की अपेक्षा की जाती है, उन्हें इस सेटिंग को ट्यून करना चाहिए।

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

DATABASE_ROUTERS

डिफ़ॉल्ट: [] (खाली सूची)

राउटर की सूची जो डेटाबेस क्वेरी का प्रदर्शन करते समय किस डेटाबेस का उपयोग करने के लिए निर्धारित की जाएगी।

मल्टी डेटाबेस कॉन्फ़िगरेशन में स्वचालित डेटाबेस रूटिंग पर प्रलेखन देखें।

DATE_FORMAT

डिफ़ॉल्ट: 'N j, Y' (जैसे Feb. 4, 2003 )

सिस्टम के किसी भी हिस्से में दिनांक फ़ील्ड प्रदर्शित करने के लिए उपयोग करने के लिए डिफ़ॉल्ट स्वरूपण। ध्यान दें कि यदि USE_L10N True सेट है, तो लोकेल- USE_L10N किए गए प्रारूप में उच्च वरीयता है और इसके बजाय लागू किया जाएगा। allowed date format strings देखें।

DATETIME_FORMAT , TIME_FORMAT और SHORT_DATE_FORMAT भी देखें।

DATE_INPUT_FORMATS

चूक:

[
    '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
    '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
    '%d %b %Y', '%d %b, %Y',            # '25 Oct 2006', '25 Oct, 2006'
    '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006'
    '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006'
]

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

जब USE_L10N True , तो स्थानीय-निर्धारित प्रारूप में उच्च वरीयता होती है और इसके बजाय इसे लागू किया जाएगा।

DATETIME_INPUT_FORMATS और TIME_INPUT_FORMATS भी देखें।

DATETIME_FORMAT

डिफ़ॉल्ट: 'N j, Y, P' (जैसे Feb. 4, 2003, 4 pm )

सिस्टम के किसी भी भाग में डेटाटाइम फ़ील्ड प्रदर्शित करने के लिए उपयोग करने के लिए डिफ़ॉल्ट स्वरूपण। ध्यान दें कि यदि USE_L10N True सेट है, तो लोकेल- USE_L10N किए गए प्रारूप में उच्च वरीयता है और इसके बजाय लागू किया जाएगा। allowed date format strings देखें।

DATE_FORMAT , TIME_FORMAT और SHORT_DATETIME_FORMAT भी देखें।

DATETIME_INPUT_FORMATS

चूक:

[
    '%Y-%m-%d %H:%M:%S',     # '2006-10-25 14:30:59'
    '%Y-%m-%d %H:%M:%S.%f',  # '2006-10-25 14:30:59.000200'
    '%Y-%m-%d %H:%M',        # '2006-10-25 14:30'
    '%Y-%m-%d',              # '2006-10-25'
    '%m/%d/%Y %H:%M:%S',     # '10/25/2006 14:30:59'
    '%m/%d/%Y %H:%M:%S.%f',  # '10/25/2006 14:30:59.000200'
    '%m/%d/%Y %H:%M',        # '10/25/2006 14:30'
    '%m/%d/%Y',              # '10/25/2006'
    '%m/%d/%y %H:%M:%S',     # '10/25/06 14:30:59'
    '%m/%d/%y %H:%M:%S.%f',  # '10/25/06 14:30:59.000200'
    '%m/%d/%y %H:%M',        # '10/25/06 14:30'
    '%m/%d/%y',              # '10/25/06'
]

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

जब USE_L10N True , तो स्थानीय-निर्धारित प्रारूप में उच्च वरीयता होती है और इसके बजाय इसे लागू किया जाएगा।

DATE_INPUT_FORMATS और TIME_INPUT_FORMATS भी देखें।

DEBUG

डिफ़ॉल्ट: False

एक बूलियन जो डिबग मोड को चालू / बंद करता है।

DEBUG=False साथ उत्पादन में साइट को कभी भी चालू न करें।

क्या आपने उसे पकड़ा? कभी भी DEBUG=False साथ उत्पादन में एक साइट को तैनात नहीं किया।

डिबग मोड की मुख्य विशेषताओं में से एक विस्तृत त्रुटि पृष्ठों का प्रदर्शन है। यदि आपका ऐप DEBUG=False True होने पर एक अपवाद को बढ़ाता है, तो Django एक विस्तृत ट्रेसबैक प्रदर्शित करेगा, जिसमें आपके वातावरण के बारे में बहुत सारे मेटाडेटा शामिल हैं, जैसे कि वर्तमान में सभी परिभाषित Django सेटिंग्स ( settings.py )।

सुरक्षा उपाय के रूप में, Django में ऐसी सेटिंग्स शामिल नहीं होंगी जो संवेदनशील हो सकती हैं, जैसे SECRET_KEY । विशेष रूप से, यह किसी भी सेटिंग को बाहर कर देगा जिसके नाम में निम्नलिखित में से कोई भी शामिल है:

• 'API'
• 'KEY'
• 'PASS'
• 'SECRET'
• 'SIGNATURE'
• 'TOKEN'

ध्यान दें कि ये आंशिक मैच हैं। 'PASS' PASSWORD से भी मेल खाएगा, जैसे 'TOKEN' भी TOKENIZED और इसी तरह मेल खाएगा।

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

यह भी याद रखना महत्वपूर्ण है कि जब DEBUG=False साथ चल रहा है, तो Django हर SQL क्वेरी को निष्पादित करेगा जो याद रखेगा। यह उपयोगी है जब आप डिबगिंग कर रहे हैं, लेकिन यह तेजी से एक उत्पादन सर्वर पर मेमोरी का उपभोग करेगा।

अंत में, यदि DEBUG=False False , तो आपको ALLOWED_HOSTS सेटिंग को भी ठीक से सेट करना होगा। ऐसा करने में विफलता के परिणामस्वरूप सभी अनुरोध "खराब अनुरोध (400)" के रूप में वापस आ जाएंगे।

DEBUG_PROPAGATE_EXCEPTIONS

डिफ़ॉल्ट: False

यदि True लिए सेट किया गया है, तो Django के अपवाद को देखने के कार्य ( handler500 , या डीबग यदि True है तो डिबग दृश्य) और 500 प्रतिसादों का लॉगिंग ( django.request ) छोड़ दिया जाता है और अपवाद ऊपर की ओर django.request ।

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

DECIMAL_SEPARATOR

डिफ़ॉल्ट: '.' (डॉट)

दशमलव संख्याओं को स्वरूपित करते समय डिफ़ॉल्ट दशमलव विभाजक का उपयोग किया जाता है।

ध्यान दें कि यदि USE_L10N True सेट है, तो लोकेल- USE_L10N किए गए प्रारूप में उच्च वरीयता है और इसके बजाय लागू किया जाएगा।

NUMBER_GROUPING , THOUSAND_SEPARATOR और USE_THOUSAND_SEPARATOR भी देखें।

DEFAULT_CHARSET

डिफ़ॉल्ट: 'utf-8'

डिफ़ॉल्ट रूप से सभी HttpResponse ऑब्जेक्ट के लिए उपयोग करने के लिए, यदि MIME प्रकार मैन्युअल रूप से निर्दिष्ट नहीं है। Content-Type हेडर के निर्माण के लिए DEFAULT_CONTENT_TYPE साथ उपयोग किया जाता है।

DEFAULT_CONTENT_TYPE

डिफ़ॉल्ट: 'text/html'

डिफ़ॉल्ट सामग्री प्रकार सभी HttpResponse ऑब्जेक्ट के लिए उपयोग करने के लिए, यदि MIME प्रकार मैन्युअल रूप से निर्दिष्ट नहीं है। Content-Type हेडर के निर्माण के लिए DEFAULT_CHARSET साथ उपयोग किया जाता है।

DEFAULT_EXCEPTION_REPORTER_FILTER

डिफ़ॉल्ट: ' django.views.debug.SafeExceptionReporterFilter '

यदि कोई भी अभी तक HttpRequest उदाहरण के लिए असाइन नहीं किया गया है, तो डिफ़ॉल्ट अपवाद रिपोर्टर फ़िल्टर वर्ग का उपयोग किया जाएगा। फ़िल्टरिंग त्रुटि रिपोर्ट देखें।

DEFAULT_FILE_STORAGE

डिफ़ॉल्ट: ' django.core.files.storage.FileSystemStorage '

किसी भी फ़ाइल-संबंधित संचालन के लिए डिफ़ॉल्ट फ़ाइल संग्रहण वर्ग का उपयोग किया जाना है जो किसी विशेष संग्रहण प्रणाली को निर्दिष्ट नहीं करता है। फ़ाइलें प्रबंधित करना देखें।

DEFAULT_FROM_EMAIL

डिफ़ॉल्ट: '[email protected]'

साइट प्रबंधक से विभिन्न स्वचालित पत्राचार के लिए उपयोग करने के लिए डिफ़ॉल्ट ईमेल पता। इसमें ADMINS और MANAGERS को भेजे गए त्रुटि संदेश शामिल नहीं हैं; उसके लिए, SERVER_EMAIL देखें।

DEFAULT_INDEX_TABLESPACE

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

खेतों पर अनुक्रमित करने के लिए डिफ़ॉल्ट तालिकाओं का उपयोग करें जो एक निर्दिष्ट नहीं करते हैं, अगर बैकेंड इसका समर्थन करता है ( Tablespaces देखें)।

DEFAULT_TABLESPACE

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

डिफ़ॉल्ट टेबलस्पेश उन मॉडलों के लिए उपयोग करने के लिए जो एक निर्दिष्ट नहीं करते हैं, यदि बैकएंड इसका समर्थन करता है ( Tablespaces देखें)।

DISALLOWED_USER_AGENTS

डिफ़ॉल्ट: [] (खाली सूची)

उपयोगकर्ता-एजेंट स्ट्रिंग्स का प्रतिनिधित्व करने वाले संकलित नियमित अभिव्यक्ति ऑब्जेक्ट्स की सूची, जिन्हें किसी भी पृष्ठ पर जाने की अनुमति नहीं है, सिस्टमवाइड। खराब रोबोट / क्रॉलर के लिए इसका उपयोग करें। इसका उपयोग केवल तभी किया जाता है जब CommonMiddleware स्थापित किया गया है ( Middleware देखें)।

EMAIL_BACKEND

डिफ़ॉल्ट: ' django.core.mail.backends.smtp.EmailBackend '

ईमेल भेजने के लिए उपयोग करने के लिए बैकएंड। उपलब्ध बैकेंड की सूची के लिए ईमेल भेजना देखें।

EMAIL_FILE_PATH

डिफ़ॉल्ट: परिभाषित नहीं है

आउटपुट फ़ाइल को संग्रहीत करने के लिए file ईमेल बैकएंड द्वारा उपयोग की जाने वाली निर्देशिका।

EMAIL_HOST

डिफ़ॉल्ट: 'localhost'

ईमेल भेजने के लिए उपयोग करने वाला होस्ट।

EMAIL_PORT भी देखें।

EMAIL_HOST_PASSWORD

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

EMAIL_HOST में परिभाषित SMTP सर्वर के लिए उपयोग करने के लिए पासवर्ड। SMTP सर्वर को प्रमाणित करते समय यह सेटिंग EMAIL_HOST_USER के साथ संयोजन में उपयोग की जाती है। यदि इनमें से कोई भी सेटिंग खाली है, तो Django प्रमाणीकरण का प्रयास नहीं करेगा।

EMAIL_HOST_USER भी देखें।

EMAIL_HOST_USER

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

EMAIL_HOST में परिभाषित SMTP सर्वर के लिए उपयोग करने के लिए उपयोगकर्ता नाम। यदि खाली है, तो Django प्रमाणीकरण का प्रयास नहीं करेगा।

EMAIL_HOST_PASSWORD भी देखें।

EMAIL_PORT

डिफ़ॉल्ट: 25

EMAIL_HOST में परिभाषित SMTP सर्वर के लिए उपयोग करने के लिए पोर्ट।

EMAIL_SUBJECT_PREFIX

डिफ़ॉल्ट: '[Django] '

django.core.mail.mail_admins या django.core.mail.mail_managers साथ भेजे गए ईमेल संदेशों के लिए विषय-पंक्ति उपसर्ग। आप शायद अनुगामी स्थान को शामिल करना चाहते हैं।

EMAIL_USE_LOCALTIME

डिफ़ॉल्ट: False

चाहे वह स्थानीय समय क्षेत्र ( True ) या UTC ( False ) में ईमेल संदेशों के SMTP Date शीर्ष लेख भेजना हो।

EMAIL_USE_TLS

डिफ़ॉल्ट: False

एसएमटीपी सर्वर से बात करते समय टीएलएस (सुरक्षित) कनेक्शन का उपयोग करना है या नहीं। यह स्पष्ट रूप से TLS कनेक्शन के लिए उपयोग किया जाता है, आम तौर पर पोर्ट 587 पर। यदि आप हैंगिंग कनेक्शन का अनुभव कर रहे हैं, तो अंतर्निहित TLS EMAIL_USE_SSL सेटिंग EMAIL_USE_SSL ।

EMAIL_USE_SSL

डिफ़ॉल्ट: False

SMTP सर्वर से बात करते समय एक अंतर्निहित TLS (सुरक्षित) कनेक्शन का उपयोग करना है या नहीं। अधिकांश ईमेल प्रलेखन में इस प्रकार के टीएलएस कनेक्शन को एसएसएल कहा जाता है। यह आमतौर पर पोर्ट 465 पर उपयोग किया जाता है। यदि आप समस्याओं का सामना कर रहे हैं, तो स्पष्ट TLS सेटिंग EMAIL_USE_TLS ।

ध्यान दें कि EMAIL_USE_TLS / EMAIL_USE_SSL पारस्परिक रूप से अनन्य हैं, इसलिए केवल उन सेटिंग्स में से एक को True सेट करें।

EMAIL_SSL_CERTFILE

डिफ़ॉल्ट: None

यदि EMAIL_USE_SSL या EMAIL_USE_TLS True , तो आप वैकल्पिक रूप से SSL कनेक्शन के लिए उपयोग करने के लिए EMAIL_USE_TLS स्वरूपित प्रमाणपत्र श्रृंखला फ़ाइल का पथ निर्दिष्ट कर सकते हैं।

EMAIL_SSL_KEYFILE

डिफ़ॉल्ट: None

यदि EMAIL_USE_SSL या EMAIL_USE_TLS True , तो आप वैकल्पिक रूप से SSL कनेक्शन के लिए उपयोग करने के लिए PEM स्वरूपित निजी कुंजी फ़ाइल का पथ निर्दिष्ट कर सकते हैं।

ध्यान दें कि EMAIL_SSL_CERTFILE और EMAIL_SSL_KEYFILE सेट करने से कोई प्रमाणपत्र जाँच नहीं होती है। वे अंतर्निहित SSL कनेक्शन को पास कर चुके हैं। कृपया प्रमाणपत्र श्रृंखला फ़ाइल और निजी कुंजी फ़ाइल को कैसे संभाला जाए, इस पर जानकारी के लिए पायथन के ssl.wrap_socket() फ़ंक्शन के दस्तावेज़ देखें।

EMAIL_TIMEOUT

डिफ़ॉल्ट: None

कनेक्शन के प्रयास की तरह संचालन अवरुद्ध करने के लिए सेकंड में एक टाइमआउट निर्दिष्ट करता है।

FILE_CHARSET

डिफ़ॉल्ट: 'utf-8'

डिस्क से पढ़ी गई किसी भी फाइल को डिकोड करने के लिए उपयोग किया जाने वाला वर्ण एन्कोडिंग। इसमें टेम्पलेट फ़ाइलें और प्रारंभिक SQL डेटा फ़ाइलें शामिल हैं।

FILE_UPLOAD_HANDLERS

चूक:

[
    'django.core.files.uploadhandler.MemoryFileUploadHandler',
    'django.core.files.uploadhandler.TemporaryFileUploadHandler',
]

अपलोड करने के लिए उपयोग करने के लिए हैंडलर की एक सूची। इस सेटिंग को बदलने से पूर्ण अनुकूलन - यहां तक ​​कि प्रतिस्थापन - Django की अपलोड प्रक्रिया की अनुमति मिलती है।

विवरण के लिए फ़ाइलों को प्रबंधित करना देखें।

FILE_UPLOAD_MAX_MEMORY_SIZE

डिफ़ॉल्ट: 2621440 (यानी 2.5 एमबी)।

अधिकतम आकार (बाइट्स में) जो अपलोड होने से पहले फाइल सिस्टम में स्ट्रीम हो जाएगा। विवरण के लिए फ़ाइलों को प्रबंधित करना देखें ।

यह भी देखें DATA_UPLOAD_MAX_MEMORY_SIZE ।

FILE_UPLOAD_DIRECTORY_PERMISSIONS

चूक: None

फ़ाइलों को अपलोड करने की प्रक्रिया में बनाई गई निर्देशिकाओं पर लागू करने के लिए संख्यात्मक मोड।

यह सेटिंग collectstatic प्रबंधन कमांड का उपयोग करते समय एकत्रित स्थिर निर्देशिकाओं के लिए डिफ़ॉल्ट अनुमतियों को भी निर्धारित करती है । collectstatic इसे ओवरराइड करने के विवरण के लिए देखें ।

यह मान FILE_UPLOAD_PERMISSIONS सेटिंग की कार्यक्षमता और कैविटीज़ को दिखाता है ।

FILE_UPLOAD_PERMISSIONS

चूक: None

0o644 नई अपलोड की गई फ़ाइलों को सेट करने के लिए संख्यात्मक मोड (यानी )। इन विधियों का क्या अर्थ है, इसके बारे में अधिक जानकारी के लिए, दस्तावेज़ देखें os.chmod() ।

यदि यह नहीं दिया गया है या नहीं है None , तो आपको ऑपरेटिंग-सिस्टम निर्भर व्यवहार मिलेगा। अधिकांश प्लेटफार्मों पर, अस्थायी फ़ाइलों में एक मोड होगा 0o600 , और मेमोरी से सहेजी गई फ़ाइलों को सिस्टम के मानक ऑमस्क का उपयोग करके सहेजा जाएगा।

सुरक्षा कारणों से, इन अनुमतियों को उन अस्थायी फ़ाइलों पर लागू नहीं किया जाता है, जो इसमें संग्रहीत हैं FILE_UPLOAD_TEMP_DIR ।

यह सेटिंग collectstatic प्रबंधन कमांड का उपयोग करते समय एकत्रित स्थिर फ़ाइलों के लिए डिफ़ॉल्ट अनुमतियों को भी निर्धारित करती है । collectstatic इसे ओवरराइड करने के विवरण के लिए देखें ।

FILE_UPLOAD_TEMP_DIR

चूक: None

फ़ाइलों FILE_UPLOAD_MAX_MEMORY_SIZE को अपलोड करते समय (आमतौर पर फ़ाइलों से बड़ी ) डेटा संग्रहीत करने की निर्देशिका । यदि None , Django ऑपरेटिंग सिस्टम के लिए मानक अस्थायी निर्देशिका का उपयोग करेगा। उदाहरण के लिए, यह /tmp * nix- शैली ऑपरेटिंग सिस्टम पर डिफ़ॉल्ट होगा ।

विवरण के लिए फ़ाइलों को प्रबंधित करना देखें ।

FIRST_DAY_OF_WEEK

डिफ़ॉल्ट: 0 (रविवार)

सप्ताह के पहले दिन का प्रतिनिधित्व करने वाली एक संख्या। कैलेंडर प्रदर्शित करते समय यह विशेष रूप से उपयोगी है। यह मान केवल तब उपयोग किया जाता है जब प्रारूप अंतर्राष्ट्रीयकरण का उपयोग नहीं किया जाता है, या जब वर्तमान स्थानीय के लिए कोई प्रारूप नहीं मिल सकता है।

मान 0 से 6 तक पूर्णांक होना चाहिए, जहां 0 का अर्थ रविवार, 1 का अर्थ सोमवार और इसी तरह है।

FIXTURE_DIRS

डिफ़ॉल्ट: [] (खाली सूची)

fixtures खोज क्रम में प्रत्येक एप्लिकेशन की निर्देशिका के अलावा, स्थिरता फ़ाइलों के लिए खोज की गई निर्देशिकाओं की सूची ।

ध्यान दें कि इन रास्तों को विंडोज पर भी यूनिक्स-स्टाइल फॉरवर्ड स्लैश का उपयोग करना चाहिए।

जुड़नार और स्थिरता लोड करने के साथ डेटा प्रदान करना देखें ।

FORCE_SCRIPT_NAME

चूक: None

यदि नहीं None , तो इसका उपयोग SCRIPT_NAME किसी भी HTTP अनुरोध में पर्यावरण चर के मान के रूप में किया जाएगा । इस सेटिंग का उपयोग सर्वर-प्रदत्त मूल्य को ओवरराइड करने के लिए किया जा सकता है SCRIPT_NAME , जो कि पसंदीदा मान का पुनर्लेखन संस्करण हो सकता है या इसकी आपूर्ति नहीं की जा सकती है। django.setup() जब SCRIPT_NAME यह नहीं है तो सही URL उत्पन्न करने के लिए अनुरोध / प्रतिक्रिया चक्र (जैसे प्रबंधन आदेश और स्टैंडअलोन स्क्रिप्ट में) के बाहर URL रिज़ॉल्वर स्क्रिप्ट उपसर्ग सेट करने के लिए भी इसका उपयोग किया जाता है / ।

FORM_RENDERER

चूक: ' django.forms.renderers.DjangoTemplates '

वह वर्ग जो विजेट बनाता है। इसे निम्न-स्तरीय रेंडर एपीआई को लागू करना होगा ।

FORMAT_MODULE_PATH

चूक: None

एक पायथन पैकेज के लिए एक पूर्ण पायथन पथ जिसमें प्रोजेक्ट स्थानों के लिए कस्टम प्रारूप परिभाषाएँ हैं। यदि नहीं None , तो Django एक formats.py फ़ाइल के लिए जाँच करेगा , जिसे वर्तमान लोकेल के रूप में नामित निर्देशिका के तहत, और इस फ़ाइल में परिभाषित स्वरूपों का उपयोग करेगा।

उदाहरण के लिए, यदि FORMAT_MODULE_PATH यह सेट है mysite.formats , और वर्तमान भाषा है en (अंग्रेजी), तो Django एक डायरेक्टरी ट्री की अपेक्षा करेगा:

mysite/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py

आप इस सेटिंग को पायथन रास्तों की सूची में भी सेट कर सकते हैं, उदाहरण के लिए:

FORMAT_MODULE_PATH = [
    'mysite.formats',
    'some_app.formats',
]

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

उपलब्ध प्रारूप हैं:

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT ,
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• YEAR_MONTH_FORMAT

IGNORABLE_404_URLS

डिफ़ॉल्ट: [] (खाली सूची)

ईमेल के माध्यम से HTTP 404 त्रुटियों की रिपोर्ट करते समय URL की व्याख्या करने वाले संकलित नियमित अभिव्यक्ति ऑब्जेक्ट्स की सूची को अनदेखा किया जाना चाहिए ( त्रुटि रिपोर्टिंग देखें )। नियमित अभिव्यक्तियों के विरुद्ध मिलान किया जाता है request's full paths (क्वेरी स्ट्रिंग सहित, यदि कोई हो)। इसका उपयोग करें यदि आपकी साइट के रूप में एक आमतौर पर अनुरोध फ़ाइल प्रदान नहीं करता है favicon.ico या robots.txt , या अगर यह स्क्रिप्ट kiddies द्वारा ठोक हो जाता है।

यह केवल तभी उपयोग किया जाता है जब BrokenLinkEmailsMiddleware सक्षम किया गया हो ( Middleware देखें )।

INSTALLED_APPS

डिफ़ॉल्ट: [] (खाली सूची)

इस Django स्थापना में सक्षम किए गए सभी अनुप्रयोगों को निर्दिष्ट करने वाले तार की एक सूची। प्रत्येक स्ट्रिंग को एक बिंदीदार अजगर पथ होना चाहिए:

• एक एप्लिकेशन कॉन्फ़िगरेशन क्लास (पसंदीदा), या
• एक पैकेज जिसमें एक एप्लिकेशन है।

एप्लिकेशन कॉन्फ़िगरेशन के बारे में अधिक जानें ।

जब कई अनुप्रयोग समान संसाधन (टेम्पलेट, स्थिर फ़ाइल, प्रबंधन आदेश, अनुवाद) के विभिन्न संस्करण प्रदान करते हैं, तो पहले सूचीबद्ध होने वाले आवेदन INSTALLED_APPS में पूर्वता है।

INTERNAL_IPS

डिफ़ॉल्ट: [] (खाली सूची)

IP पते की एक सूची, तार के रूप में, जो:

• debug() टेम्प्लेट के संदर्भ में कुछ चर जोड़ने के लिए संदर्भ प्रोसेसर को अनुमति दें ।
• यदि कोई कर्मचारी उपयोगकर्ता के रूप में लॉग इन नहीं है, तो भी बुकमार्क बुकमार्क का उपयोग कर सकते हैं ।
• AdminEmailHandler ईमेल में "आंतरिक" ("बाहरी" के विपरीत) के रूप में चिह्नित हैं ।

LANGUAGE_CODE

चूक: 'en-us'

इस स्थापना के लिए भाषा कोड का प्रतिनिधित्व करने वाला एक स्ट्रिंग। यह मानक भाषा आईडी प्रारूप में होना चाहिए । उदाहरण के लिए, यूएस इंग्लिश है "en-us" । भाषा पहचानकर्ताओं और अंतर्राष्ट्रीयकरण और स्थानीयकरण की सूची भी देखें ।

USE_I18N इस सेटिंग का कोई प्रभाव होने के लिए सक्रिय होना चाहिए।

यह दो उद्देश्य प्रदान करता है:

• यदि लोकेल मिडलवेयर उपयोग में नहीं है, तो यह तय करता है कि सभी उपयोगकर्ताओं को कौन सा अनुवाद परोसा जाए।
• यदि लोकल मिडलवेयर सक्रिय है, तो यह उपयोगकर्ता को पसंदीदा भाषा निर्धारित नहीं होने या वेबसाइट द्वारा समर्थित नहीं होने की स्थिति में एक फेकबैक भाषा प्रदान करता है। जब उपयोगकर्ता की पसंदीदा भाषा के लिए किसी दिए गए शाब्दिक के लिए अनुवाद मौजूद नहीं होता है तो यह भी फॉलबैक अनुवाद प्रदान करता है।

देखें कि कैसे अधिक जानकारी के लिए Django भाषा की प्राथमिकता का पता लगाता है ।

LANGUAGE_COOKIE_AGE

डिफ़ॉल्ट: None (ब्राउज़र बंद होने की समय सीमा समाप्त)

भाषा कुकी की उम्र, सेकंड में।

LANGUAGE_COOKIE_DOMAIN

चूक: None

डोमेन भाषा कुकी के लिए उपयोग करने के लिए। इसे एक स्ट्रिंग पर सेट करें जैसे कि "example.com" क्रॉस-डोमेन कुकीज़, या None मानक डोमेन कुकी के लिए उपयोग करें ।

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

LANGUAGE_COOKIE_NAME

चूक: 'django_language'

भाषा कुकी के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)। अंतर्राष्ट्रीयकरण और स्थानीयकरण देखें ।

LANGUAGE_COOKIE_PATH

चूक: '/'

भाषा कुकी पर निर्धारित पथ। यह या तो आपके Django इंस्टॉलेशन के URL पथ से मेल खाना चाहिए या उस पथ का माता-पिता होना चाहिए।

यदि आपके पास एक ही होस्टनाम के तहत कई Django इंस्टेंसेस चल रहे हैं तो यह उपयोगी है। वे विभिन्न कुकी पथों का उपयोग कर सकते हैं और प्रत्येक उदाहरण केवल अपनी भाषा कुकी देखेंगे।

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

LANGUAGES

डिफ़ॉल्ट: सभी उपलब्ध भाषाओं की एक सूची। यह सूची लगातार बढ़ रही है और यहां एक प्रति सहित अनिवार्य रूप से तेजी से पुरानी हो जाएगी। आप अनुवादित भाषाओं की वर्तमान सूची देख सकते हैं django/conf/global_settings.py (या ऑनलाइन स्रोत देख सकते हैं )।

सूची प्रारूप में दो tuples (की एक सूची है भाषा कोड , language name - उदाहरण के लिए) ('ja', 'Japanese') । यह निर्दिष्ट करता है कि भाषा चयन के लिए कौन सी भाषाएं उपलब्ध हैं। अंतर्राष्ट्रीयकरण और स्थानीयकरण देखें ।

आम तौर पर, डिफ़ॉल्ट मान पर्याप्त होना चाहिए। केवल यह सेटिंग सेट करें यदि आप भाषा चयन को Django प्रदान की गई भाषाओं के सबसेट तक सीमित करना चाहते हैं।

यदि आप एक कस्टम LANGUAGES सेटिंग को परिभाषित करते हैं, तो आप gettext_lazy() फ़ंक्शन का उपयोग करके भाषा के नामों को अनुवाद स्ट्रिंग के रूप में चिह्नित कर सकते हैं ।

यहाँ एक नमूना सेटिंग्स फ़ाइल है:

from django.utils.translation import gettext_lazy as _

LANGUAGES = [
    ('de', _('German')),
    ('en', _('English')),
]

LOCALE_PATHS

डिफ़ॉल्ट: [] (खाली सूची)

निर्देशिका की एक सूची जहां Django अनुवाद फ़ाइलों के लिए दिखता है। देखें कि कैसे Django अनुवाद का पता चलता है ।

उदाहरण:

LOCALE_PATHS = [
    '/home/www/project/common_files/locale',
    '/var/local/translations/locale',
]

Django <locale_code>/LC_MESSAGES वास्तविक अनुवाद फ़ाइलों वाली निर्देशिकाओं के लिए इनमें से प्रत्येक पथ के भीतर दिखेगा ।

LOGGING

डिफ़ॉल्ट: एक लॉगिंग कॉन्फ़िगरेशन शब्दकोश।

कॉन्फ़िगरेशन जानकारी युक्त डेटा संरचना। इस डेटा संरचना की सामग्री में वर्णित विन्यास विधि के तर्क के रूप में पारित किया जाएगा LOGGING_CONFIG ।

अन्य बातों के अलावा, डिफ़ॉल्ट लॉगिंग विन्यास एक ई-मेल लॉग हैंडलर को HTTP 500 सर्वर त्रुटियों से गुजरता है जब DEBUG=False है False । लॉगिंग कॉन्फ़िगर करना भी देखें ।

आप django/utils/log.py (या ऑनलाइन स्रोत को देखने के लिए ) डिफ़ॉल्ट लॉगिंग कॉन्फ़िगरेशन देख सकते हैं ।

LOGGING_CONFIG

चूक: 'logging.config.dictConfig'

एक कॉल करने योग्य का पथ जिसका उपयोग Django परियोजना में लॉगिंग को कॉन्फ़िगर करने के लिए किया जाएगा। डिफ़ॉल्ट रूप से पायथन के dictConfig विन्यास विधि के एक उदाहरण पर अंक ।

यदि आप सेट LOGGING_CONFIG करते हैं None , तो लॉगिंग कॉन्फ़िगरेशन प्रक्रिया को छोड़ दिया जाएगा।

MANAGERS

डिफ़ॉल्ट: [] (खाली सूची)

उसी प्रारूप में एक सूची ADMINS जो निर्दिष्ट करती है कि BrokenLinkEmailsMiddleware सक्षम होने पर टूटी हुई लिंक सूचनाएं किसे मिलनी चाहिए।

MEDIA_ROOT

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों को रखने वाली निर्देशिका के लिए पूर्ण फ़ाइल सिस्टम पथ ।

उदाहरण: "/var/www/example.com/media/"

यह भी देखें MEDIA_URL ।

MEDIA_URL

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

URL जो मीडिया से सेव किया गया है MEDIA_ROOT , संग्रहीत फ़ाइलों के प्रबंधन के लिए उपयोग किया जाता है । यदि कोई खाली-खाली मान पर सेट किया गया हो, तो उसे स्लैश में समाप्त होना चाहिए। आपको इन फ़ाइलों को विकास और उत्पादन वातावरण दोनों में सेवा के लिए कॉन्फ़िगर करना होगा ।

यदि आप {{ MEDIA_URL }} अपने टेम्प्लेट में उपयोग करना चाहते हैं 'django.template.context_processors.media' , तो 'context_processors' विकल्प में जोड़ें TEMPLATES ।

उदाहरण: "http://media.example.com/"

MIDDLEWARE

चूक: None

उपयोग करने के लिए मिडलवेयर की एक सूची। Middleware देखें ।

MIGRATION_MODULES

डिफ़ॉल्ट: {} (खाली शब्दकोश)

पैकेज को निर्दिष्ट करने वाला एक शब्दकोश जहां माइग्रेशन मॉड्यूल प्रति-ऐप के आधार पर पाया जा सकता है। इस सेटिंग का डिफ़ॉल्ट मान एक खाली शब्दकोश है, लेकिन माइग्रेशन मॉड्यूल के लिए डिफ़ॉल्ट पैकेज नाम है migrations ।

उदाहरण:

{'blog': 'blog.db_migrations'}

इस स्थिति में, blog एप्लिकेशन से संबंधित माइग्रेशन blog.db_migrations पैकेज में समाहित हो जाएंगे ।

यदि आप app_label तर्क प्रदान करते हैं, makemigrations तो यह पहले से मौजूद नहीं होने पर स्वचालित रूप से पैकेज बनाएगा।

जब आप None किसी ऐप के लिए एक मूल्य के रूप में आपूर्ति करते हैं , तो Django मौजूदा migrations सबमॉड्यूल की परवाह किए बिना माइग्रेशन के बिना ऐप के रूप में ऐप पर विचार करेगा । इसका उपयोग, उदाहरण के लिए, परीक्षण करते समय माइग्रेशन को छोड़ने के लिए एक परीक्षण सेटिंग फ़ाइल में किया जा सकता है (ऐप के मॉडल के लिए टेबल अभी भी बनाए जाएंगे)। यदि यह आपके सामान्य प्रोजेक्ट सेटिंग्स में उपयोग किया जाता है, migrate --run-syncdb तो विकल्प का उपयोग करना याद रखें यदि आप ऐप के लिए टेबल बनाना चाहते हैं।

MONTH_DAY_FORMAT

चूक: 'F j'

Django व्यवस्थापक परिवर्तन-सूची पृष्ठों पर दिनांक फ़ील्ड के लिए उपयोग करने के लिए डिफ़ॉल्ट स्वरूपण - और, संभवतः, सिस्टम के अन्य भागों द्वारा - उन मामलों में जब केवल महीने और दिन प्रदर्शित होते हैं।

उदाहरण के लिए, जब एक Django व्यवस्थापक परिवर्तन-सूची पृष्ठ को डेट ड्रिलडाउन द्वारा फ़िल्टर किया जा रहा है, तो किसी दिए गए दिन का हेडर दिन और महीने प्रदर्शित करता है। विभिन्न स्थानों के अलग-अलग प्रारूप हैं। उदाहरण के लिए, अमेरिकी अंग्रेजी "1 जनवरी" कहेगी, जबकि स्पेनिश "1 एनरो" कह सकती है।

ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो संबंधित स्थान-निर्धारित प्रारूप में उच्च वरीयता है और इसे लागू किया जाएगा।

देख लो allowed date format strings । यह भी देखें DATE_FORMAT , DATETIME_FORMAT , TIME_FORMAT और YEAR_MONTH_FORMAT ।

NUMBER_GROUPING

चूक: 0

किसी संख्या के पूर्णांक भाग पर एक साथ समूहीकृत अंकों की संख्या।

आम उपयोग एक हजार विभाजक प्रदर्शित करने के लिए है। यदि यह सेटिंग है 0 , तो नंबर पर कोई समूहीकरण लागू नहीं किया जाएगा। यदि यह सेटिंग से अधिक है 0 , तो THOUSAND_SEPARATOR उन समूहों के बीच विभाजक के रूप में उपयोग किया जाएगा।

कुछ स्थान गैर-समान अंक समूहन का उपयोग करते हैं, उदाहरण 10,00,00,000 के लिए en_IN । इस स्थिति के लिए, आप लागू किए जाने वाले अंकों के समूह आकारों की संख्या के साथ एक अनुक्रम प्रदान कर सकते हैं। पहली संख्या दशमलव सीमांकक से पहले समूह के आकार को परिभाषित करती है, और प्रत्येक संख्या जो निम्न समूहों के आकार को परिभाषित करती है। यदि अनुक्रम को समाप्त कर दिया जाता है -1 , तो आगे कोई समूहन नहीं किया जाता है। यदि अनुक्रम एक के साथ समाप्त होता है 0 , तो अंतिम समूह आकार का उपयोग शेष संख्या के लिए किया जाता है।

उदाहरण के लिए टपल en_IN :

NUMBER_GROUPING = (3, 2, 0)

ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो स्थानीय-निर्धारित प्रारूप में उच्च प्राथमिकता है और इसके बजाय लागू किया जाएगा।

यह भी देखें DECIMAL_SEPARATOR , THOUSAND_SEPARATOR और USE_THOUSAND_SEPARATOR ।

PREPEND_WWW

चूक: False

चाहे "www।" को पूर्व-निर्धारित करें, जिन URL के पास यह नहीं है। यह केवल तभी उपयोग किया जाता है यदि CommonMiddleware इंस्टॉल किया गया है ( Middleware देखें )। यह भी देखें APPEND_SLASH ।

ROOT_URLCONF

डिफ़ॉल्ट: परिभाषित नहीं है

आपके रूट URLconf में पूर्ण पायथन आयात पथ का प्रतिनिधित्व करने वाला एक स्ट्रिंग। उदाहरण के लिए "mydjangoapps.urls" :। urlconf आवक HttpRequest ऑब्जेक्ट पर विशेषता सेट करके प्रति-अनुरोध के आधार पर ओवरराइड किया जा सकता है । देखें कि कैसे Django विवरण के लिए अनुरोध संसाधित करता है ।

SECRET_KEY

डिफ़ॉल्ट: '' (खाली स्ट्रिंग)

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

django-admin startproject स्वचालित रूप SECRET_KEY से प्रत्येक नई परियोजना के लिए एक यादृच्छिक रूप से उत्पन्न जोड़ता है ।

कुंजी के उपयोगों को यह नहीं मानना ​​चाहिए कि यह पाठ या बाइट्स है। प्रत्येक उपयोग को गुजरना चाहिए force_text() या force_bytes() इसे वांछित प्रकार में बदलना चाहिए ।

SECRET_KEY सेट नहीं होने पर Django शुरू करने से इनकार कर देगा ।

गुप्त कुंजी का उपयोग इसके लिए किया जाता है:

• सभी sessions यदि आप किसी अन्य सत्र बैकएंड django.contrib.sessions.backends.cache का उपयोग कर रहे हैं, या डिफ़ॉल्ट का उपयोग कर रहे हैं get_session_auth_hash() ।
• सभी messages यदि आप उपयोग कर रहे हैं CookieStorage या FallbackStorage ।
• सभी PasswordResetView टोकन।
• क्रिप्टोग्राफ़िक हस्ताक्षर का कोई उपयोग , जब तक कि एक अलग कुंजी प्रदान नहीं की जाती है।

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

SECURE_BROWSER_XSS_FILTER

चूक: False

यदि True , X-XSS- सुरक्षा SecurityMiddleware सेट करता है : 1; मोड = सभी प्रतिक्रियाओं पर हेडर को ब्लॉक करें जो पहले से नहीं है।

SECURE_CONTENT_TYPE_NOSNIFF

चूक: False

यदि True , X-Content-Type-Options: nosniff हैडर को उन सभी प्रतिक्रियाओं पर SecurityMiddleware सेट करता है जो पहले से नहीं है।

SECURE_HSTS_INCLUDE_SUBDOMAINS

चूक: False

यदि True , HTTP सख्त परिवहन सुरक्षा हेडर SecurityMiddleware में includeSubDomains निर्देश जोड़ता है । इसका कोई प्रभाव नहीं है जब तक कि यह एक शून्य-शून्य मान पर सेट न हो । SECURE_HSTS_SECONDS

SECURE_HSTS_PRELOAD

चूक: False

यदि True , HTTP सख्त परिवहन सुरक्षा हेडर SecurityMiddleware में preload निर्देश जोड़ता है । इसका कोई प्रभाव नहीं है जब तक कि यह एक शून्य-शून्य मान पर सेट न हो । SECURE_HSTS_SECONDS

SECURE_HSTS_SECONDS

चूक: 0

यदि एक गैर-शून्य पूर्णांक मान पर SecurityMiddleware सेट किया गया है , तो HTTP स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी हेडर उन सभी प्रतिक्रियाओं पर सेट करता है जो पहले से ही नहीं है।

SECURE_PROXY_SSL_HEADER

चूक: None

HTTP हेडर / मान संयोजन का प्रतिनिधित्व करने वाला एक टपल सुरक्षित है जो अनुरोध को दर्शाता है। यह अनुरोध ऑब्जेक्ट की is_secure() विधि के व्यवहार को नियंत्रित करता है ।

यह कुछ स्पष्टीकरण लेता है। डिफ़ॉल्ट रूप से, is_secure() यह निर्धारित करने में सक्षम है कि अनुरोधित URL का उपयोग करके कोई अनुरोध सुरक्षित है या नहीं https:// । यह Django के CSRF सुरक्षा के लिए महत्वपूर्ण है, और इसका उपयोग आपके स्वयं के कोड या तृतीय-पक्ष एप्लिकेशन द्वारा किया जा सकता है।

यदि आपका Django ऐप एक प्रॉक्सी के पीछे है, हालांकि, प्रॉक्सी इस तथ्य को "निगल" सकता है कि प्रॉक्सी और Django के बीच एक गैर-HTTPS कनेक्शन का उपयोग करते हुए, एक अनुरोध HTTPS है। इस मामले में, is_secure() हमेशा वापसी करेंगे False - यहां तक ​​कि उन अनुरोधों के लिए जो एचटीटीपीएस के माध्यम से अंतिम उपयोगकर्ता द्वारा किए गए थे।

इस स्थिति में, आप एक कस्टम HTTP हेडर सेट करने के लिए अपने प्रॉक्सी को कॉन्फ़िगर करना चाहते हैं जो Django को बताता है कि क्या अनुरोध HTTPS के माध्यम से आया है, और आप सेट करना चाहते हैं SECURE_PROXY_SSL_HEADER ताकि Django को पता चले कि किस हेडर को देखना है।

आपको दो तत्वों के साथ एक टपल सेट करने की आवश्यकता होगी - देखने के लिए हेडर का नाम और आवश्यक मूल्य। उदाहरण के लिए:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

यहां, हम Django को बता रहे हैं कि हम उस X-Forwarded-Proto हेडर पर भरोसा करते हैं जो हमारे प्रॉक्सी से आता है, और किसी भी समय इसका मूल्य है 'https' , तो अनुरोध सुरक्षित होने की गारंटी है (यानी, यह मूल रूप से HTTPS के माध्यम से आया था)। जाहिर है, आपको केवल इस सेटिंग को सेट करना चाहिए यदि आप अपने प्रॉक्सी को नियंत्रित करते हैं या कुछ अन्य गारंटी है कि यह इस हेडर को उचित रूप से सेट / स्ट्रिप्स करता है।

ध्यान दें कि शीर्ष लेख को प्रारूप में उपयोग करने की आवश्यकता है request.META - सभी कैप और संभावना के साथ शुरू HTTP_ । (याद रखें, 'HTTP_' हेडर उपलब्ध कराने से पहले , Django स्वचालित रूप से x- हेडर नामों की शुरुआत को जोड़ता है request.META ।

SECURE_REDIRECT_EXEMPT

डिफ़ॉल्ट: [] (खाली सूची)

यदि URL पथ इस सूची में एक नियमित अभिव्यक्ति से मेल खाता है, तो अनुरोध HTTPS पर पुनर्निर्देशित नहीं किया जाएगा। यदि SECURE_SSL_REDIRECT है False , तो इस सेटिंग का कोई प्रभाव नहीं है।

SECURE_SSL_HOST

चूक: None

यदि एक स्ट्रिंग (जैसे secure.example.com ), सभी SSL पुनर्निर्देशन को मूल रूप से अनुरोधित होस्ट (जैसे www.example.com ) के बजाय इस होस्ट को निर्देशित किया जाएगा । यदि SECURE_SSL_REDIRECT है False , तो इस सेटिंग का कोई प्रभाव नहीं है।

SECURE_SSL_REDIRECT

चूक: False

यदि True , HTTPS के लिए सभी गैर-HTTPS अनुरोधों को redirects करता है (उन URL को छोड़कर जो एक नियमित रूप से सूचीबद्ध अभिव्यक्ति से मेल खाते हैं )। SecurityMiddleware redirects SECURE_REDIRECT_EXEMPT

SERIALIZATION_MODULES

डिफ़ॉल्ट: परिभाषित नहीं है

क्रमबद्ध प्रकार के लिए एक स्ट्रिंग पहचानकर्ता द्वारा कुंजीबद्ध धारावाहिक परिभाषाओं (स्ट्रिंग के रूप में प्रदान) वाले मॉड्यूल का शब्दकोश। उदाहरण के लिए, एक YAML धारावाहिक को परिभाषित करने के लिए, उपयोग करें:

SERIALIZATION_MODULES = {'yaml': 'path.to.yaml_serializer'}

SERVER_EMAIL

चूक: '[email protected]'

ईमेल संदेश जिसमें त्रुटि संदेश आते हैं, जैसे कि भेजे गए ADMINS और MANAGERS ।

SHORT_DATE_FORMAT

डिफ़ॉल्ट: 'm/d/Y' (जैसे 12/31/2003 )

एक उपलब्ध प्रारूपण जिसका उपयोग टेम्प्लेट पर दिनांक फ़ील्ड प्रदर्शित करने के लिए किया जा सकता है। ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो संबंधित स्थान-निर्धारित प्रारूप में उच्च वरीयता है और इसे लागू किया जाएगा। देख लो allowed date format strings ।

यह भी देखें DATE_FORMAT और SHORT_DATETIME_FORMAT ।

SHORT_DATETIME_FORMAT

डिफ़ॉल्ट: 'm/d/Y P' (जैसे 12/31/2003 4 pm )

एक उपलब्ध प्रारूपण जिसका उपयोग टेम्पलेट्स पर डेटाइम क्षेत्रों को प्रदर्शित करने के लिए किया जा सकता है। ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो संबंधित स्थान-निर्धारित प्रारूप में उच्च वरीयता है और इसे लागू किया जाएगा। देख लो allowed date format strings ।

यह भी देखें DATE_FORMAT और SHORT_DATE_FORMAT ।

SIGNING_BACKEND

चूक: 'django.core.signing.TimestampSigner'

कुकीज़ और अन्य डेटा पर हस्ताक्षर करने के लिए उपयोग किया जाने वाला बैकेंड।

क्रिप्टोग्राफ़िक हस्ताक्षर दस्तावेज़ भी देखें ।

SILENCED_SYSTEM_CHECKS

डिफ़ॉल्ट: [] (खाली सूची)

सिस्टम चेक फ्रेमवर्क (यानी ["models.W001"] ) द्वारा उत्पन्न संदेशों के पहचानकर्ताओं की एक सूची जिसे आप स्थायी रूप से स्वीकार करना और अनदेखा करना चाहते हैं। साइलेंट चेक कंसोल में आउटपुट नहीं होंगे।

सिस्टम चेक फ्रेमवर्क प्रलेखन भी देखें ।

TEMPLATES

डिफ़ॉल्ट: [] (खाली सूची)

Django के साथ उपयोग किए जाने वाले सभी टेम्पलेट इंजनों के लिए सेटिंग्स वाली एक सूची। सूची का प्रत्येक आइटम एक शब्दकोश है जिसमें एक व्यक्तिगत इंजन के विकल्प हैं।

यहाँ एक सरल सेटअप है जो Django टेम्पलेट इंजन को templates प्रत्येक स्थापित एप्लिकेशन के अंदर उपनिर्देशिका से टेम्पलेट लोड करने के लिए कहता है :

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'APP_DIRS': True,
    },
]

सभी बैकएंड के लिए निम्न विकल्प उपलब्ध हैं।

BACKEND

डिफ़ॉल्ट: परिभाषित नहीं है

टेम्पलेट उपयोग करने के लिए बैकएंड करता है। अंतर्निहित टेम्पलेट बैकएंड हैं:

• 'django.template.backends.django.DjangoTemplates'
• 'django.template.backends.jinja2.Jinja2'

आप एक टेम्पलेट बैकएंड का उपयोग कर सकते हैं जो BACKEND पूरी तरह से योग्य पथ (यानी 'mypackage.whatever.Backend' ) पर सेट करके Django के साथ जहाज नहीं करता है ।

NAME

डिफ़ॉल्ट: नीचे देखें

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

यह इंजन वर्ग को परिभाषित करने वाले मॉड्यूल के नाम को डिफॉल्ट करता है, अर्थात BACKEND जब यह प्रदान नहीं किया जाता है, तो अगले अंतिम टुकड़े तक । उदाहरण के लिए यदि बैकएंड है 'mypackage.whatever.Backend' तो उसका डिफ़ॉल्ट नाम है 'whatever' ।

DIRS

डिफ़ॉल्ट: [] (खाली सूची)

निर्देशिकाएँ जहां खोज क्रम में इंजन को टेम्पलेट स्रोत फ़ाइलों के लिए दिखना चाहिए।

APP_DIRS

चूक: False

चाहे इंजन स्थापित अनुप्रयोगों के अंदर टेम्पलेट स्रोत फ़ाइलों के लिए दिखना चाहिए।

OPTIONS

डिफ़ॉल्ट: {} (खाली तानाशाही)

टेम्पलेट बैकएंड को पास करने के लिए अतिरिक्त पैरामीटर। उपलब्ध पैरामीटर टेम्पलेट बैकएंड के आधार पर भिन्न होते हैं। अंतर्निहित बैकएंड के विकल्पों के लिए देखें DjangoTemplates और Jinja2 ।

TEST_RUNNER

चूक: 'django.test.runner.DiscoverRunner'

टेस्ट सूट शुरू करने के लिए उपयोग करने वाले वर्ग का नाम। विभिन्न परीक्षण रूपरेखाओं का उपयोग करना देखें ।

TEST_NON_SERIALIZED_APPS

डिफ़ॉल्ट: [] (खाली सूची)

TransactionTestCase लेनदेन के बिना एस और डेटाबेस के बैकएंड के लिए परीक्षणों के बीच डेटाबेस राज्य को पुनर्स्थापित करने के लिए , Django serialized_rollback=True को serialized_rollback=True करेगा जब यह टेस्ट रन शुरू करता है, तो यह परीक्षण चलाने से पहले उस कॉपी से फिर से लोड कर सकता है जिसे इसकी आवश्यकता है।

यह परीक्षण धावक के स्टार्टअप समय को धीमा कर देता है; यदि आपके पास ऐसे ऐप्स हैं जिन्हें आप जानते हैं कि इस सुविधा की आवश्यकता नहीं है, तो आप 'django.contrib.contenttypes' उन्हें इस क्रमबद्ध प्रक्रिया से बाहर करने के लिए उनके पूर्ण नाम यहाँ (जैसे ) जोड़ सकते हैं ।

THOUSAND_SEPARATOR

डिफ़ॉल्ट: ',' (कोमा)

संख्याओं को स्वरूपित करते समय डिफ़ॉल्ट हजार विभाजक का उपयोग किया जाता है। यह सेटिंग केवल इस्तेमाल किया जब है USE_THOUSAND_SEPARATOR है True और NUMBER_GROUPING से बड़ा है 0 ।

ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो स्थानीय-निर्धारित प्रारूप में उच्च प्राथमिकता है और इसके बजाय लागू किया जाएगा।

यह भी देखें NUMBER_GROUPING , DECIMAL_SEPARATOR और USE_THOUSAND_SEPARATOR ।

TIME_FORMAT

डिफ़ॉल्ट: 'P' (जैसे 4 pm )

सिस्टम के किसी भी हिस्से में समय क्षेत्र प्रदर्शित करने के लिए उपयोग करने के लिए डिफ़ॉल्ट स्वरूपण। ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो स्थानीय-निर्धारित प्रारूप में उच्च प्राथमिकता है और इसके बजाय लागू किया जाएगा। देख लो allowed date format strings ।

यह भी देखें DATE_FORMAT और DATETIME_FORMAT ।

TIME_INPUT_FORMATS

चूक:

[
    '%H:%M:%S',     # '14:30:59'
    '%H:%M:%S.%f',  # '14:30:59.000200'
    '%H:%M',        # '14:30'
]

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

जब USE_L10N है True , तो स्थानीय-निर्धारित प्रारूप में उच्च प्राथमिकता होती है और इसके बजाय लागू किया जाएगा।

यह भी देखें DATE_INPUT_FORMATS और DATETIME_INPUT_FORMATS ।

TIME_ZONE

चूक: 'America/Chicago'

इस स्थापना के लिए समय क्षेत्र का प्रतिनिधित्व करने वाला एक स्ट्रिंग। समय क्षेत्र की सूची देखें ।

ध्यान दें कि यह आवश्यक रूप से सर्वर का समय क्षेत्र नहीं है। उदाहरण के लिए, एक सर्वर कई Django- संचालित साइटों की सेवा कर सकता है, प्रत्येक एक अलग समय क्षेत्र सेटिंग के साथ।

कब USE_TZ है False , यह समय क्षेत्र है जिसमें Django सभी डेटासेट को संग्रहीत करेगा। कब USE_TZ है True , यह डिफ़ॉल्ट समय क्षेत्र है जो Django टेम्पलेट्स में डेटासेट प्रदर्शित करने और रूपों में दर्ज किए गए डेटासेट की व्याख्या करने के लिए उपयोग करेगा।

यूनिक्स वातावरण (जहां time.tzset() लागू होता है) पर, Django os.environ['TZ'] चर को उस समय क्षेत्र में सेट करता है जिसे आप TIME_ZONE सेटिंग में निर्दिष्ट करते हैं। इस प्रकार, आपके सभी विचार और मॉडल इस समय क्षेत्र में स्वचालित रूप से काम करेंगे। हालाँकि, Django TZ पर्यावरण चर को सेट नहीं करेगा यदि आप मैन्युअल कॉन्फ़िगरेशन विकल्प का उपयोग कर रहे हैं जैसा कि मैन्युअल रूप से सेटिंग में कॉन्फ़िगर किया गया है । यदि Django TZ पर्यावरण चर को सेट नहीं करता है , तो यह सुनिश्चित करना आपके लिए सही प्रक्रिया में चल रही प्रक्रियाएं हैं।

USE_I18N

चूक: True

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

यह भी देखें LANGUAGE_CODE , USE_L10N और USE_TZ ।

USE_L10N

चूक: False

एक बूलियन जो निर्दिष्ट करता है कि डेटा का स्थानीय स्वरूपण डिफ़ॉल्ट रूप से सक्षम होगा या नहीं। यदि यह करने के लिए सेट है True , जैसे Django वर्तमान स्थान के प्रारूप का उपयोग करके संख्या और दिनांक प्रदर्शित करेगा।

यह भी देखें LANGUAGE_CODE , USE_I18N और USE_TZ ।

USE_THOUSAND_SEPARATOR

चूक: False

एक बूलियन जो निर्दिष्ट करता है कि एक हजार विभाजक का उपयोग करके संख्याओं को प्रदर्शित करना है या नहीं। जब USE_L10N सेट किया जाता है True और अगर यह भी सेट हो जाता है True , तो Django के मानों का उपयोग THOUSAND_SEPARATOR और NUMBER_GROUPING संख्याओं को प्रारूपित करने के लिए होगा, जब तक कि लोकेल में पहले से मौजूद हजारों विभाजक न हों। यदि स्थानीय प्रारूप में हजारों विभाजक हैं, तो इसकी उच्च प्राथमिकता होगी और इसके बजाय इसे लागू किया जाएगा।

यह भी देखें DECIMAL_SEPARATOR , NUMBER_GROUPING और THOUSAND_SEPARATOR ।

USE_TZ

चूक: False

एक बूलियन जो निर्दिष्ट करता है कि क्या डेटाटाइम डिफ़ॉल्ट रूप से टाइमज़ोन-जागरूक होगा या नहीं। यदि यह निर्धारित किया जाता है True , तो Django आंतरिक रूप से टाइमज़ोन-अवगत डेटाटाइम का उपयोग करेगा। अन्यथा, Django स्थानीय समय में भोले डेटासेट का उपयोग करेगा।

यह भी देखें TIME_ZONE , USE_I18N और USE_L10N ।

USE_X_FORWARDED_HOST

चूक: False

एक बूलियन जो निर्दिष्ट करता है कि क्या X-Forwarded-Host हेडर को वरीयता में हेडर का उपयोग करना है या नहीं Host । यह केवल तभी सक्षम होना चाहिए जब एक प्रॉक्सी जो इस हेडर को सेट करता है उपयोग में है।

यह सेटिंग प्राथमिकता से अधिक है USE_X_FORWARDED_PORT । प्रति आरएफसी 7239 # पेज -7 , X-Forwarded-Host हैडर पोर्ट संख्या, जिस स्थिति में आप प्रयोग नहीं करना चाहिए शामिल कर सकते हैं USE_X_FORWARDED_PORT ।

USE_X_FORWARDED_PORT

चूक: False

एक बूलियन जो निर्दिष्ट करता है कि क्या वैरिएबल X-Forwarded-Port को वरीयता में हेडर का उपयोग करना है SERVER_PORT META । यह केवल तभी सक्षम होना चाहिए जब एक प्रॉक्सी जो इस हेडर को सेट करता है उपयोग में है।

USE_X_FORWARDED_HOST इस सेटिंग पर प्राथमिकता लेता है।

WSGI_APPLICATION

चूक: None

WSGI एप्लिकेशन ऑब्जेक्ट का पूर्ण पायथन पथ जो Django के अंतर्निहित सर्वर (जैसे runserver ) का उपयोग करेगा। django-admin startproject प्रबंधन आदेश एक सरल बनाएगा wsgi.py एक साथ फ़ाइल application उस में प्रतिदेय, और कहा कि इस सेटिंग को इंगित application ।

यदि सेट नहीं किया गया है, तो वापसी मूल्य का django.core.wsgi.get_wsgi_application() उपयोग किया जाएगा। इस स्थिति में, व्यवहार runserver पिछले Django संस्करणों के समान होगा।

YEAR_MONTH_FORMAT

चूक: 'F Y'

Django व्यवस्थापक परिवर्तन-सूची पृष्ठों पर दिनांक फ़ील्ड के लिए उपयोग करने के लिए डिफ़ॉल्ट स्वरूपण - और, संभवतः, सिस्टम के अन्य भागों द्वारा - ऐसे मामलों में जब केवल वर्ष और महीने प्रदर्शित होते हैं।

उदाहरण के लिए, जब एक Django व्यवस्थापक परिवर्तन-सूची पृष्ठ को डेट ड्रिलडाउन द्वारा फ़िल्टर किया जा रहा है, तो किसी दिए गए महीने का हेडर महीने और वर्ष प्रदर्शित करता है। विभिन्न स्थानों के अलग-अलग प्रारूप हैं। उदाहरण के लिए, अमेरिकी अंग्रेजी "जनवरी 2006" कहेगी, जबकि एक अन्य स्थानीय व्यक्ति "2006 / जनवरी" कह सकता है।

ध्यान दें कि यदि USE_L10N सेट किया गया है True , तो संबंधित स्थान-निर्धारित प्रारूप में उच्च वरीयता है और इसे लागू किया जाएगा।

देख लो allowed date format strings । यह भी देखें DATE_FORMAT , DATETIME_FORMAT , TIME_FORMAT और MONTH_DAY_FORMAT ।

X_FRAME_OPTIONS

चूक: 'SAMEORIGIN'

द्वारा उपयोग किए गए X- फ्रेम-ऑप्शन हेडर के लिए डिफ़ॉल्ट मान XFrameOptionsMiddleware । क्लिकज़ैकिंग सुरक्षा दस्तावेज़ देखें ।

प्रमाणीकरण

के लिए सेटिंग्स django.contrib.auth ।

AUTHENTICATION_BACKENDS

चूक: ['django.contrib.auth.backends.ModelBackend']

उपयोगकर्ता को प्रमाणित करने का प्रयास करते समय उपयोग करने के लिए प्रमाणीकरण बैकेंड कक्षाओं (स्ट्रिंग्स के रूप में) की एक सूची। प्रमाणीकरण देखें विवरण के लिए प्रलेखन का समर्थन करता है।

AUTH_USER_MODEL

चूक: 'auth.User'

उपयोगकर्ता का प्रतिनिधित्व करने के लिए उपयोग करने के लिए मॉडल। एक कस्टम उपयोगकर्ता मॉडल को प्रतिस्थापित करना देखें ।

LOGIN_REDIRECT_URL

चूक: '/accounts/profile/'

वह URL जहां अनुरोधों को लॉगिन के बाद पुनर्निर्देशित किया contrib.auth.login जाता है जब दृश्य को कोई next पैरामीटर नहीं मिलता है ।

login_required() उदाहरण के लिए, डेकोरेटर द्वारा इसका उपयोग किया जाता है ।

यह सेटिंग उस URL पैटर्न को भी स्वीकार करती है जिसका उपयोग कॉन्फ़िगरेशन दोहराव को कम करने के लिए किया जा सकता है क्योंकि आपको URL को दो स्थानों ( settings और URLconf) में परिभाषित नहीं करना है ।

LOGIN_URL

चूक: '/accounts/login/'

वह URL जहाँ अनुरोध लॉगिन के लिए पुनर्निर्देशित किए जाते हैं, विशेष रूप से login_required() सज्जाकार का उपयोग करते समय ।

यह सेटिंग उस URL पैटर्न को भी स्वीकार करती है जिसका उपयोग कॉन्फ़िगरेशन दोहराव को कम करने के लिए किया जा सकता है क्योंकि आपको URL को दो स्थानों ( settings और URLconf) में परिभाषित नहीं करना है ।

LOGOUT_REDIRECT_URL

चूक: None

वह URL जहां उपयोगकर्ता द्वारा लॉग आउट करने के बाद अनुरोधों को पुनर्निर्देशित किया जाता है LogoutView (यदि दृश्य में next_page तर्क नहीं मिलता है )।

यदि None , कोई पुनर्निर्देशन नहीं किया जाएगा और लॉगआउट दृश्य प्रस्तुत किया जाएगा।

यह सेटिंग उस URL पैटर्न को भी स्वीकार करती है जिसका उपयोग कॉन्फ़िगरेशन दोहराव को कम करने के लिए किया जा सकता है क्योंकि आपको URL को दो स्थानों ( settings और URLconf) में परिभाषित नहीं करना है ।

PASSWORD_RESET_TIMEOUT_DAYS

चूक: 3

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

द्वारा उपयोग किया जाता है PasswordResetConfirmView ।

PASSWORD_HASHERS

देखें कि कैसे Django पासवर्ड संग्रहीत करता है ।

चूक:

[
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]

AUTH_PASSWORD_VALIDATORS

डिफ़ॉल्ट: [] (खाली सूची)

सत्यापनकर्ताओं की सूची जो उपयोगकर्ता के पासवर्ड की ताकत की जांच करने के लिए उपयोग की जाती है। देखें पासवर्ड सत्यापन अधिक जानकारी के लिए। डिफ़ॉल्ट रूप से, कोई सत्यापन नहीं किया जाता है और सभी पासवर्ड स्वीकार किए जाते हैं।

संदेश

के लिए सेटिंग्स django.contrib.messages ।

MESSAGE_LEVEL

चूक: messages.INFO

संदेश फ्रेमवर्क द्वारा रिकॉर्ड किए जाने वाले न्यूनतम संदेश स्तर को सेट करता है। देखें संदेश स्तरों अधिक जानकारी के लिए।

from django.contrib.messages import constants as message_constants
MESSAGE_LEVEL = message_constants.DEBUG

MESSAGE_STORAGE

चूक: 'django.contrib.messages.storage.fallback.FallbackStorage'

नियंत्रण जहाँ Django संदेश डेटा संग्रहीत करता है। मान्य मान हैं:

• 'django.contrib.messages.storage.fallback.FallbackStorage'
• 'django.contrib.messages.storage.session.SessionStorage'
• 'django.contrib.messages.storage.cookie.CookieStorage'

देखें संदेश भंडारण बैकेंड अधिक जानकारी के लिए।

बैकएंड जो कुकीज़ का उपयोग करते हैं - CookieStorage और FallbackStorage - और उनके कुकीज़ सेट करते समय SESSION_COOKIE_DOMAIN , के मूल्य का उपयोग करते हैं। SESSION_COOKIE_SECURE SESSION_COOKIE_HTTPONLY

MESSAGE_TAGS

चूक:

{
    messages.DEBUG: 'debug',
    messages.INFO: 'info',
    messages.SUCCESS: 'success',
    messages.WARNING: 'warning',
    messages.ERROR: 'error',
}

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

from django.contrib.messages import constants as message_constants
MESSAGE_TAGS = {message_constants.INFO: ''}

सत्र

के लिए सेटिंग्स django.contrib.sessions ।

SESSION_CACHE_ALIAS

चूक: 'default'

यदि आप कैश-आधारित सत्र संग्रहण का उपयोग कर रहे हैं , तो यह उपयोग करने के लिए कैश का चयन करता है।

SESSION_COOKIE_AGE

डिफ़ॉल्ट: 1209600 (2 सप्ताह, सेकंड में)

सत्र कुकीज़ की आयु, सेकंड में।

SESSION_COOKIE_DOMAIN

चूक: None

सत्र कुकीज़ के लिए उपयोग करने के लिए डोमेन। इसे एक स्ट्रिंग पर सेट करें जैसे कि "example.com" क्रॉस-डोमेन कुकीज़, या None मानक डोमेन कुकी के लिए उपयोग करें ।

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

यह सेटिंग द्वारा निर्धारित कुकीज़ को भी प्रभावित करती है django.contrib.messages ।

SESSION_COOKIE_HTTPONLY

चूक: True

HTTPOnly सत्र कुकी पर ध्वज का उपयोग करना है या नहीं । यदि यह सेट हो जाता है True , तो क्लाइंट-साइड जावास्क्रिप्ट सत्र कुकी तक पहुंचने में सक्षम नहीं होगा।

HTTPOnly एक ध्वज है जो सेट-कुकी HTTP प्रतिक्रिया शीर्षलेख में शामिल है। यह कुकीज़ के लिए RFC 2109 मानक का हिस्सा नहीं है , और यह सभी ब्राउज़रों द्वारा लगातार सम्मानित नहीं किया जाता है। हालाँकि, जब इसे सम्मानित किया जाता है, तो यह सुरक्षित कुकी डेटा तक पहुँचने वाले क्लाइंट साइड स्क्रिप्ट के जोखिम को कम करने का एक उपयोगी तरीका हो सकता है।

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

SESSION_COOKIE_NAME

चूक: 'sessionid'

सत्र के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)।

SESSION_COOKIE_PATH

चूक: '/'

सत्र कुकी पर निर्धारित पथ। यह या तो आपके Django इंस्टॉलेशन के URL पथ से मेल खाना चाहिए या उस पथ का जनक होना चाहिए।

यदि आपके पास एक ही होस्टनाम के तहत कई Django इंस्टेंसेस चल रहे हैं तो यह उपयोगी है। वे अलग-अलग कुकी पथों का उपयोग कर सकते हैं, और प्रत्येक उदाहरण को केवल अपना सत्र कुकी दिखाई देगा।

SESSION_COOKIE_SAMESITE

चूक: 'Lax'

सत्र कुकी पर SameSite ध्वज का मूल्य । यह ध्वज कुकी को क्रॉस-साइट अनुरोधों में भेजे जाने से रोकता है और इस प्रकार CSRF हमलों को रोकता है और सत्र कुकी को चोरी करने के कुछ तरीकों को असंभव बना देता है।

सेटिंग के लिए संभावित मान हैं:

• 'Strict' : नियमित लिंक का पालन करते हुए भी कुकी को ब्राउजर द्वारा सभी क्रॉस-साइट ब्राउज़िंग संदर्भ में लक्ष्य साइट पर भेजे जाने से रोकता है।

  उदाहरण के लिए, GitHub जैसी वेबसाइट के लिए इसका मतलब यह होगा कि यदि लॉग-इन उपयोगकर्ता किसी कॉर्पोरेट चर्चा मंच या ईमेल पर पोस्ट किए गए निजी GitHub प्रोजेक्ट के लिंक का अनुसरण करता है, GitHub सत्र कुकी प्राप्त नहीं करेगा और उपयोगकर्ता नहीं करेगा परियोजना का उपयोग करने में सक्षम। एक बैंक वेबसाइट, हालांकि, सबसे अधिक संभावना है कि किसी भी लेन-देन के पन्नों को बाहरी साइटों से जोड़ने की अनुमति नहीं देना चाहती है, इसलिए 'Strict' झंडा उपयुक्त होगा।

• 'Lax' (डिफ़ॉल्ट): उन वेबसाइटों के लिए सुरक्षा और उपयोगिता के बीच संतुलन प्रदान करता है जो उपयोगकर्ता को बाहरी लिंक से आने के बाद उपयोगकर्ता के लॉग-इन सत्र को बनाए रखना चाहते हैं।

  GitHub परिदृश्य में, सत्र कुकी को किसी बाहरी वेबसाइट से नियमित लिंक का पालन करने और CSRF- प्रवण अनुरोध विधियों (जैसे POST ) में अवरुद्ध होने की अनुमति होगी ।

• None : ध्वज को निष्क्रिय करता है।

SESSION_COOKIE_SECURE

चूक: False

सत्र कुकी के लिए सुरक्षित कुकी का उपयोग करना है या नहीं। यदि इसे सेट किया जाता है True , तो कुकी को "सुरक्षित" के रूप में चिह्नित किया जाएगा, जिसका अर्थ है कि ब्राउज़र यह सुनिश्चित कर सकते हैं कि कुकी केवल HTTPS कनेक्शन के तहत भेजी गई है।

चूँकि एक पैकेट स्निफ़र (जैसे कि Firesheep ) के लिए यह एक उपयोगकर्ता के सत्र को अपहृत करने के लिए तुच्छ है, यदि सत्र कुकी को अनएन्क्रिप्टेड भेजा जाता है, तो इसे छोड़ने का कोई अच्छा बहाना नहीं है। यह आपको असुरक्षित अनुरोधों पर सत्रों का उपयोग करने से रोकेगा और यह अच्छी बात है।

SESSION_ENGINE

चूक: 'django.contrib.sessions.backends.db'

नियंत्रण जहाँ Django सत्र डेटा संग्रहीत करता है। शामिल इंजन हैं:

• 'django.contrib.sessions.backends.db'
• 'django.contrib.sessions.backends.file'
• 'django.contrib.sessions.backends.cache'
• 'django.contrib.sessions.backends.cached_db'
• 'django.contrib.sessions.backends.signed_cookies'

देखें सत्र इंजन का विन्यास अधिक जानकारी के लिए।

SESSION_EXPIRE_AT_BROWSER_CLOSE

चूक: False

जब उपयोगकर्ता अपने ब्राउज़र को बंद करता है, तो सत्र को समाप्त करना है। देखें ब्राउज़र-लंबाई सत्र बनाम लगातार सत्रों ।

SESSION_FILE_PATH

चूक: None

यदि आप फ़ाइल-आधारित सत्र संग्रहण का उपयोग कर रहे हैं, तो यह उस निर्देशिका को सेट करता है जिसमें Django सत्र डेटा संग्रहीत करेगा। जब डिफ़ॉल्ट मान ( None ) का उपयोग किया जाता है, तो Django सिस्टम के लिए मानक अस्थायी निर्देशिका का उपयोग करेगा।

SESSION_SAVE_EVERY_REQUEST

चूक: False

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

SESSION_SERIALIZER

चूक: 'django.contrib.sessions.serializers.JSONSerializer'

क्रमबद्ध सत्र डेटा का उपयोग करने के लिए एक धारावाहिक वर्ग का पूर्ण आयात पथ। शामिल धारावाहिक हैं:

• 'django.contrib.sessions.serializers.PickleSerializer'
• 'django.contrib.sessions.serializers.JSONSerializer'

देखें सत्र क्रमबद्धता , जानकारी के लिए संभव दूरस्थ कोड निष्पादन का उपयोग करते समय के बारे में एक चेतावनी सहित PickleSerializer ।

साइटें

के लिए सेटिंग्स django.contrib.sites ।

SITE_ID

डिफ़ॉल्ट: परिभाषित नहीं है

django_site डेटाबेस तालिका में वर्तमान साइट के पूर्णांक के रूप में आईडी । इसका उपयोग इसलिए किया जाता है ताकि एप्लिकेशन डेटा विशिष्ट साइटों पर हुक कर सकें और एक एकल डेटाबेस कई साइटों के लिए सामग्री का प्रबंधन कर सके।

स्थैतिक फ़ाइलें

के लिए सेटिंग्स django.contrib.staticfiles ।

STATIC_ROOT

चूक: None

निर्देशिका के लिए पूर्ण पथ जहाँ पर collectstatic परिनियोजन के लिए स्थिर फ़ाइलों को एकत्रित करेगा।

उदाहरण: "/var/www/example.com/static/"

यदि staticfiles कंट्रीब ऐप सक्षम है (डिफ़ॉल्ट प्रोजेक्ट टेम्प्लेट के रूप में), तो collectstatic प्रबंधन कमांड इस डायरेक्टरी में स्टैटिक फाइल्स एकत्रित करेगा। उपयोग के बारे में अधिक जानकारी के लिए स्थैतिक फ़ाइलों को प्रबंधित करने का तरीका देखें ।

STATIC_URL

चूक: None

स्थैतिक फ़ाइलों का संदर्भ देते समय उपयोग करने वाला URL STATIC_ROOT ।

उदाहरण: "/static/" या "http://static.example.com/"

यदि नहीं None , तो इसका उपयोग संपत्ति परिभाषाओं ( Media वर्ग) और staticfiles लिए आधार पथ के रूप में किया जाएगा ।

यदि कोई खाली-खाली मान पर सेट किया गया हो, तो उसे स्लैश में समाप्त होना चाहिए।

आपको इन फ़ाइलों को विकास में प्रस्तुत करने के लिए कॉन्फ़िगर करने की आवश्यकता हो सकती है और निश्चित रूप से उत्पादन में ऐसा करने की आवश्यकता होगी ।

STATICFILES_DIRS

डिफ़ॉल्ट: [] (खाली सूची)

यह सेटिंग अतिरिक्त स्थानों को परिभाषित करती है यदि FileSystemFinder फाइंडर को सक्षम किया जाता है, तो स्टेटिकफाइल्स ऐप आगे बढ़ जाएगा , जैसे यदि आप collectstatic या findstatic प्रबंधन कमांड का उपयोग करते हैं या स्टेटिक फाइल सर्विंग दृश्य का उपयोग करते हैं।

इसे उन स्ट्रिंग्स की सूची पर सेट किया जाना चाहिए, जिनमें आपकी अतिरिक्त फ़ाइलों की निर्देशिका के लिए पूर्ण पथ हैं (जैसे)

STATICFILES_DIRS = [
    "/home/special.polls.com/polls/static",
    "/home/polls.com/polls/static",
    "/opt/webfiles/common",
]

ध्यान दें कि इन रास्तों को विंडोज (जैसे "C:/Users/user/mysite/extra_static_content" ) पर भी यूनिक्स-स्टाइल फॉरवर्ड स्लैश का उपयोग करना चाहिए ।

उपसर्ग (वैकल्पिक)

यदि आप अतिरिक्त नाम स्थान वाले किसी एक स्थान पर फ़ाइलों को संदर्भित करना चाहते हैं, तो आप वैकल्पिक रूप से (prefix, path) ट्यूपल्स के रूप में एक उपसर्ग प्रदान कर सकते हैं , जैसे:

STATICFILES_DIRS = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]

उदाहरण के लिए, यह मानकर कि आपने STATIC_URL सेट किया है '/static/' , collectstatic प्रबंधन कमांड "आँकड़े" फ़ाइलों को एक 'downloads' उपनिर्देशिका में एकत्रित करेगा STATIC_ROOT ।

यह आपको स्थानीय फ़ाइल को संदर्भित करने की अनुमति होगी '/opt/webfiles/stats/polls_20101022.tar.gz' के साथ '/static/downloads/polls_20101022.tar.gz' अपने टेम्पलेट, जैसे में:

<a href="{% static "downloads/polls_20101022.tar.gz" %}">

STATICFILES_STORAGE

चूक: 'django.contrib.staticfiles.storage.StaticFilesStorage'

फ़ाइल संग्रहण इंजन का उपयोग जब collectstatic प्रबंधन कमांड के साथ स्थिर फ़ाइलों को इकट्ठा करने में होता है ।

इस सेटिंग में परिभाषित स्टोरेज बैकएंड का रेडी-टू-यूज़ उदाहरण पाया जा सकता है django.contrib.staticfiles.storage.staticfiles_storage ।

उदाहरण के लिए, क्लाउड सेवा या CDN से स्थिर फ़ाइलों की सेवा देखें ।

STATICFILES_FINDERS

चूक:

[
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]

खोजक की सूची में पता चलता है कि विभिन्न स्थानों में स्थिर फ़ाइलों को कैसे जाना जाता है।

डिफ़ॉल्ट को STATICFILES_DIRS सेटिंग में संग्रहीत फ़ाइलों का उपयोग करना (उपयोग करना django.contrib.staticfiles.finders.FileSystemFinder ) और static प्रत्येक एप्लिकेशन के उपनिर्देशिका में (उपयोग करना ) मिलेगा django.contrib.staticfiles.finders.AppDirectoriesFinder । यदि समान नाम वाली कई फाइलें मौजूद हैं, तो जो पहली फाइल मिली है उसका उपयोग किया जाएगा।

एक खोजक डिफ़ॉल्ट रूप से अक्षम है django.contrib.staticfiles.finders.DefaultStorageFinder :। यदि आपकी STATICFILES_FINDERS सेटिंग में जोड़ा जाता है , तो यह DEFAULT_FILE_STORAGE सेटिंग द्वारा परिभाषित डिफ़ॉल्ट फ़ाइल संग्रहण में स्थिर फ़ाइलों के लिए दिखेगा ।

स्टेटिक फ़ाइल फ़ाइंडर्स को वर्तमान में एक निजी इंटरफ़ेस माना जाता है, और यह इंटरफ़ेस इस प्रकार अनिर्दिष्ट है।

कोर सेटिंग्स सामयिक सूचकांक

कैश

• CACHES
• CACHE_MIDDLEWARE_ALIAS
• CACHE_MIDDLEWARE_KEY_PREFIX
• CACHE_MIDDLEWARE_SECONDS

डेटाबेस

• DATABASES
• DATABASE_ROUTERS
• DEFAULT_INDEX_TABLESPACE
• DEFAULT_TABLESPACE

डिबगिंग

• DEBUG=False
• DEBUG_PROPAGATE_EXCEPTIONS

ईमेल

• ADMINS
• DEFAULT_CHARSET
• DEFAULT_FROM_EMAIL
• EMAIL_BACKEND
• EMAIL_FILE_PATH
• EMAIL_HOST
• EMAIL_HOST_PASSWORD
• EMAIL_HOST_USER
• EMAIL_PORT
• EMAIL_SSL_CERTFILE
• EMAIL_SSL_KEYFILE
• EMAIL_SUBJECT_PREFIX
• EMAIL_TIMEOUT
• EMAIL_USE_LOCALTIME
• EMAIL_USE_TLS
• MANAGERS
• SERVER_EMAIL

त्रुटि की सूचना देना

• DEFAULT_EXCEPTION_REPORTER_FILTER
• IGNORABLE_404_URLS
• MANAGERS
• SILENCED_SYSTEM_CHECKS

फ़ाइल अपलोड

• DEFAULT_FILE_STORAGE
• FILE_CHARSET
• FILE_UPLOAD_HANDLERS
• FILE_UPLOAD_MAX_MEMORY_SIZE
• FILE_UPLOAD_PERMISSIONS
• FILE_UPLOAD_TEMP_DIR
• MEDIA_ROOT
• MEDIA_URL

फार्म

• FORM_RENDERER

वैश्वीकरण ( i18n / l10n )

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• FORMAT_MODULE_PATH
• LANGUAGE_CODE
• LANGUAGE_COOKIE_AGE
• LANGUAGE_COOKIE_DOMAIN
• LANGUAGE_COOKIE_NAME
• LANGUAGE_COOKIE_PATH
• LANGUAGES
• LOCALE_PATHS
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• TIME_ZONE
• USE_I18N
• USE_L10N
• USE_THOUSAND_SEPARATOR
• USE_TZ
• YEAR_MONTH_FORMAT

एचटीटीपी

• DATA_UPLOAD_MAX_MEMORY_SIZE
• DATA_UPLOAD_MAX_NUMBER_FIELDS
• DEFAULT_CHARSET
• DEFAULT_CONTENT_TYPE
• DISALLOWED_USER_AGENTS
• FORCE_SCRIPT_NAME
• INTERNAL_IPS
• MIDDLEWARE
• सुरक्षा
  • SECURE_BROWSER_XSS_FILTER
  • SECURE_CONTENT_TYPE_NOSNIFF
  • SECURE_HSTS_INCLUDE_SUBDOMAINS
  • SECURE_HSTS_PRELOAD
  • SECURE_HSTS_SECONDS
  • SECURE_PROXY_SSL_HEADER
  • SECURE_REDIRECT_EXEMPT
  • SECURE_SSL_HOST
  • SECURE_SSL_REDIRECT
• SIGNING_BACKEND
• USE_X_FORWARDED_HOST
• USE_X_FORWARDED_PORT
• WSGI_APPLICATION

लॉगिंग

• LOGGING
• LOGGING_CONFIG

मॉडल के

• ABSOLUTE_URL_OVERRIDES
• FIXTURE_DIRS
• INSTALLED_APPS

सुरक्षा

• क्रॉस साइट अनुरोध सुरक्षा संरक्षण
  • CSRF_COOKIE_DOMAIN
  • CSRF_COOKIE_NAME
  • CSRF_COOKIE_PATH
  • CSRF_COOKIE_SAMESITE
  • CSRF_COOKIE_SECURE
  • CSRF_FAILURE_VIEW
  • CSRF_HEADER_NAME
  • CSRF_TRUSTED_ORIGINS
  • CSRF_USE_SESSIONS
• SECRET_KEY
• X_FRAME_OPTIONS

क्रमबद्धता

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

टेम्पलेट्स

• TEMPLATES

परिक्षण

• डेटाबेस: TEST
• TEST_NON_SERIALIZED_APPS
• TEST_RUNNER

यूआरएल

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF

Original text

Contribute a better translation