Django 2.1
Settings

Settings
चेतावनी
जब आप सेटिंग्स को ओवरराइड करते हैं तो सावधान रहें, खासकर जब डिफ़ॉल्ट मान एक गैर-खाली सूची या शब्दकोश हो, जैसे कि
STATICFILES_FINDERS
।
सुनिश्चित करें कि आप Django की सुविधाओं द्वारा उपयोग किए जाने वाले घटकों को रखना चाहते हैं।
कोर सेटिंग्स
यहाँ 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
CSRF कुकीज़ की आयु, सेकंड में।
उपयोगकर्ता द्वारा किसी ब्राउज़र को बंद करने या किसी पृष्ठ को बुकमार्क करने और फिर उस पृष्ठ को ब्राउज़र कैश से लोड करने की स्थिति में लंबे समय तक रहने की समय सीमा निर्धारित करने का कारण है। लगातार कुकीज़ के बिना, फ़ॉर्म जमा करना इस मामले में विफल होगा।
कुछ ब्राउज़र (विशेष रूप से इंटरनेट एक्सप्लोरर) लगातार कुकीज़ के उपयोग को बाधित कर सकते हैं या डिस्क पर दूषित कुकी जार को अनुक्रमित कर सकते हैं, जिससे CSRF सुरक्षा जांच (कभी-कभी रुक-रुक कर) विफल हो जाती है।
सत्र-आधारित CSRF कुकीज़ का उपयोग करने के लिए इस सेटिंग को
None
परिवर्तित न करें, जो लगातार भंडारण के बजाय कुकीज़ को स्मृति में रखते हैं।
CSRF_COOKIE_DOMAIN
CSRF कुकी सेट करते समय उपयोग किया जाने वाला डोमेन।
यह क्रॉस-सबडोमेन अनुरोधों को आसानी से अनुमति देने के लिए उपयोगी हो सकता है जिन्हें सामान्य क्रॉस साइट अनुरोध जालसाजी संरक्षण से बाहर रखा जा सकता है।
इसे
"example.com"
जैसे एक स्ट्रिंग पर सेट किया जाना चाहिए ताकि एक उप-डोमेन से किसी फ़ॉर्म से POST अनुरोध को किसी अन्य उपडोमेन से प्राप्त दृश्य द्वारा स्वीकार किया जा सके।
कृपया ध्यान दें कि इस सेटिंग की उपस्थिति का मतलब यह नहीं है कि Django की CSRF सुरक्षा डिफ़ॉल्ट रूप से क्रॉस-सबडोमेन हमलों से सुरक्षित है - कृपया CSRF सीमाएं अनुभाग देखें।
CSRF_COOKIE_HTTPONLY
CSRF कुकी पर
HttpOnly
ध्वज का उपयोग करना है या नहीं।
यदि यह सही पर सेट है, तो क्लाइंट-साइड जावास्क्रिप्ट CSRF कुकी को एक्सेस करने में सक्षम नहीं होगा।
CSRF कुकी को
HttpOnly
रूप में नामित करना किसी भी व्यावहारिक सुरक्षा की पेशकश नहीं करता है क्योंकि CSRF केवल क्रॉस-डोमेन हमलों से बचाने के लिए है।
यदि कोई हमलावर कुकी को जावास्क्रिप्ट के माध्यम से पढ़ सकता है, तो वे पहले से ही उसी डोमेन पर हैं जहां तक ब्राउज़र जानता है, इसलिए वे वैसे भी कुछ भी कर सकते हैं।
(XSS CSRF की तुलना में बहुत बड़ा छेद है।)
हालाँकि सेटिंग थोड़ा व्यावहारिक लाभ प्रदान करती है, लेकिन कभी-कभी सुरक्षा ऑडिटरों द्वारा इसकी आवश्यकता होती है।
यदि आप इसे सक्षम करते हैं और AJAX अनुरोध के साथ CSRF टोकन का मूल्य भेजने की आवश्यकता होती है, तो आपके जावास्क्रिप्ट को कुकी के बजाय पृष्ठ पर एक छिपे हुए CSRF टोकन फॉर्म इनपुट से मूल्य को खींचना होगा।
HttpOnly
पर विवरण के लिए
SESSION_COOKIE_HTTPONLY
देखें।
CSRF_COOKIE_NAME
CSRF प्रमाणीकरण टोकन के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)। क्रॉस साइट अनुरोध फोर्जरी सुरक्षा देखें।
CSRF_COOKIE_PATH
CSRF कुकी पर पथ सेट किया गया। यह या तो आपके Django इंस्टॉलेशन के URL पथ से मेल खाना चाहिए या उस पथ का माता-पिता होना चाहिए।
यदि आपके पास एक ही होस्टनाम के तहत कई Django इंस्टेंसेस चल रहे हैं तो यह उपयोगी है। वे अलग-अलग कुकी पथों का उपयोग कर सकते हैं, और प्रत्येक उदाहरण केवल अपने स्वयं के CSRF कुकी को देखेंगे।
CSRF_COOKIE_SAMESITE
डिफ़ॉल्ट:
'Lax'
CSRF कुकी पर SameSite ध्वज का मूल्य। यह ध्वज कुकी को क्रॉस-साइट अनुरोधों में भेजे जाने से रोकता है।
समान के बारे में विवरण के लिए
SESSION_COOKIE_SAMESITE
देखें।
CSRF_COOKIE_SECURE
सीएसआरएफ कुकी के लिए सुरक्षित कुकी का उपयोग करना है या नहीं। यदि यह सही पर सेट है, तो कुकी को "सुरक्षित" के रूप में चिह्नित किया जाएगा, जिसका अर्थ है कि ब्राउज़र यह सुनिश्चित कर सकते हैं कि कुकी केवल 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)" के रूप में वापस आ जाएंगे।
ध्यान दें
django-admin startproject
द्वारा बनाई गई डिफ़ॉल्ट
settings.py
फ़ाइल सुविधा के लिए
DEBUG = True
सेट करती है।
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
साथ उपयोग किया जाता है।
संस्करण 2.0 के बाद से पदावनत: यह सेटिंग पदावनत है क्योंकि यह तृतीय-पक्ष एप्लिकेशन के साथ अच्छी तरह से सहभागिता नहीं करता है और अप्रचलित है क्योंकि HTML5 में ज्यादातर एक्सएचटीएमएल है।
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
इसे ओवरराइड करने के विवरण
के
लिए
देखें
।
चेतावनी
हमेशा 0 के साथ मोड को उपसर्ग करें।
यदि आप फ़ाइल मोड से परिचित नहीं हैं, तो कृपया ध्यान दें कि अग्रणी
0
बहुत महत्वपूर्ण है: यह एक ऑक्टल नंबर को इंगित करता है, जो कि उस तरीके को निर्दिष्ट करना चाहिए।
यदि आप उपयोग करने का प्रयास करते हैं
644
, तो आपको पूरी तरह से गलत व्यवहार मिलेगा।
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
सीधे
एक्सेस नहीं करना चाहिए
।
django.apps.apps
इसके बजाय
उपयोग करें
।
एप्लिकेशन नाम और लेबल अद्वितीय होने चाहिए
INSTALLED_APPS
आवेदन
names
- आवेदन पैकेज के लिए बिंदीदार पायथन पथ - अद्वितीय होना चाहिए।
एक ही एप्लिकेशन को दो बार शामिल करने का कोई तरीका नहीं है, इसके कोड को किसी अन्य नाम के तहत डुप्लिकेट करने का छोटा।
आवेदन
labels
- डिफ़ॉल्ट रूप से नाम का अंतिम भाग - अद्वितीय होना चाहिए।
उदाहरण के लिए, आप दोनों को शामिल नहीं कर सकते हैं
django.contrib.auth
और
myproject.auth
।
हालांकि, आप एक कस्टम कॉन्फ़िगरेशन के साथ किसी एप्लिकेशन को रिले कर सकते हैं जो एक अलग परिभाषित करता है
labels
।
ये नियम इस बात पर ध्यान दिए बिना लागू होते हैं कि क्या
INSTALLED_APPS
संदर्भ कॉन्फ़िगरेशन क्लासेस या एप्लिकेशन पैकेज हैं।
जब कई अनुप्रयोग समान संसाधन (टेम्पलेट, स्थिर फ़ाइल, प्रबंधन आदेश, अनुवाद) के विभिन्न संस्करण प्रदान करते हैं, तो पहले सूचीबद्ध होने वाले आवेदन
INSTALLED_APPS
में पूर्वता है।
INTERNAL_IPS
डिफ़ॉल्ट:
[]
(खाली सूची)
IP पते की एक सूची, तार के रूप में, जो:
-
debug()
टेम्प्लेट के संदर्भ में कुछ चर जोड़ने के लिए संदर्भ प्रोसेसर को अनुमति दें । - यदि कोई कर्मचारी उपयोगकर्ता के रूप में लॉग इन नहीं है, तो भी बुकमार्क बुकमार्क का उपयोग कर सकते हैं ।
-
AdminEmailHandler
ईमेल में "आंतरिक" ("बाहरी" के विपरीत) के रूप में चिह्नित हैं ।
LANGUAGE_CODE
चूक:
'en-us'
इस स्थापना के लिए भाषा कोड का प्रतिनिधित्व करने वाला एक स्ट्रिंग।
यह मानक
भाषा आईडी प्रारूप
में होना चाहिए
।
उदाहरण के लिए, यूएस इंग्लिश है
"en-us"
।
भाषा पहचानकर्ताओं
और
अंतर्राष्ट्रीयकरण और स्थानीयकरण
की
सूची
भी देखें
।
USE_I18N
इस सेटिंग का कोई प्रभाव होने के लिए सक्रिय होना चाहिए।
यह दो उद्देश्य प्रदान करता है:
- यदि लोकेल मिडलवेयर उपयोग में नहीं है, तो यह तय करता है कि सभी उपयोगकर्ताओं को कौन सा अनुवाद परोसा जाए।
- यदि लोकल मिडलवेयर सक्रिय है, तो यह उपयोगकर्ता को पसंदीदा भाषा निर्धारित नहीं होने या वेबसाइट द्वारा समर्थित नहीं होने की स्थिति में एक फेकबैक भाषा प्रदान करता है। जब उपयोगकर्ता की पसंदीदा भाषा के लिए किसी दिए गए शाब्दिक के लिए अनुवाद मौजूद नहीं होता है तो यह भी फॉलबैक अनुवाद प्रदान करता है।
देखें कि कैसे अधिक जानकारी के लिए Django भाषा की प्राथमिकता का पता लगाता है ।
LANGUAGE_COOKIE_AGE
भाषा कुकी की उम्र, सेकंड में।
LANGUAGE_COOKIE_DOMAIN
डोमेन भाषा कुकी के लिए उपयोग करने के लिए।
इसे एक स्ट्रिंग पर सेट करें जैसे कि
"example.com"
क्रॉस-डोमेन कुकीज़, या
None
मानक डोमेन कुकी के लिए
उपयोग करें
।
उत्पादन साइट पर इस सेटिंग को अपडेट करते समय सतर्क रहें।
यदि आप किसी ऐसी साइट पर क्रॉस-डोमेन कुकीज़ को सक्षम करने के लिए इस सेटिंग को अपडेट करते हैं, जो पहले मानक डोमेन कुकीज़ का उपयोग करती थी, तो मौजूदा उपयोगकर्ता कुकीज़ जिनके पास पुराना डोमेन है, अपडेट नहीं किया जाएगा।
इसके परिणामस्वरूप साइट उपयोगकर्ता भाषा को तब तक स्विच करने में असमर्थ होंगे जब तक ये कुकीज़ बनी रहती हैं।
स्विच करने का एकमात्र सुरक्षित और विश्वसनीय विकल्प भाषा कुकी नाम को स्थायी रूप से (
LANGUAGE_COOKIE_NAME
सेटिंग के
माध्यम से
)
बदलना
और एक मिडलवेयर जोड़ना है जो पुराने कुकी से मूल्य को एक नए में कॉपी करता है और फिर पुराने को हटा देता है।
LANGUAGE_COOKIE_NAME
भाषा कुकी के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)। अंतर्राष्ट्रीयकरण और स्थानीयकरण देखें ।
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_ROOT
और
STATIC_ROOT
अलग-अलग मूल्य होने चाहिए।
STATIC_ROOT
पेश करने
से पहले
,
MEDIA_ROOT
स्थैतिक फ़ाइलों की सेवा के
लिए भरोसा करना या कम करना आम था
;
हालांकि, चूंकि इसमें गंभीर सुरक्षा निहितार्थ हो सकते हैं, इसलिए इसे रोकने के लिए एक सत्यापन जाँच है।
MEDIA_URL
डिफ़ॉल्ट:
''
(खाली स्ट्रिंग)
URL जो मीडिया से सेव किया गया है
MEDIA_ROOT
,
संग्रहीत फ़ाइलों के प्रबंधन के
लिए उपयोग किया
जाता है
।
यदि कोई खाली-खाली मान पर सेट किया गया हो, तो उसे स्लैश में समाप्त होना चाहिए।
आपको
इन फ़ाइलों को
विकास और उत्पादन वातावरण दोनों में
सेवा के
लिए
कॉन्फ़िगर
करना होगा
।
यदि आप
{{ MEDIA_URL }}
अपने टेम्प्लेट में
उपयोग करना चाहते
हैं
'django.template.context_processors.media'
, तो
'context_processors'
विकल्प
में
जोड़ें
TEMPLATES
।
उदाहरण:
"http://media.example.com/"
चेतावनी
यदि आप अविश्वसनीय उपयोगकर्ताओं से अपलोड की गई सामग्री स्वीकार कर रहे हैं तो सुरक्षा जोखिम हैं! शमन विवरण के लिए उपयोगकर्ता द्वारा अपलोड की गई सामग्री पर सुरक्षा गाइड के विषय को देखें।
चेतावनी
MEDIA_URL
और
STATIC_URL
अलग-अलग मूल्य होने चाहिए।
MEDIA_ROOT
अधिक जानकारी
के
लिए देखें।
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 शुरू करने से इनकार कर देगा
।
चेतावनी
इस मूल्य को गुप्त रखें।
Django के एक ज्ञात
SECRET_KEY
हार के
साथ चल रहा है Django
सुरक्षा सुरक्षा के कई, और विशेषाधिकार वृद्धि और दूरस्थ कोड निष्पादन कमजोरियों को जन्म दे सकता है।
गुप्त कुंजी का उपयोग इसके लिए किया जाता है:
-
सभी
sessions
यदि आप किसी अन्य सत्र बैकएंड
django.contrib.sessions.backends.cache
का उपयोग कर रहे हैं, या डिफ़ॉल्ट का उपयोग कर रहे हैंget_session_auth_hash()
। -
सभी
messages
यदि आप उपयोग कर रहे हैं
CookieStorage
याFallbackStorage
। -
सभी
PasswordResetView
टोकन। - क्रिप्टोग्राफ़िक हस्ताक्षर का कोई उपयोग , जब तक कि एक अलग कुंजी प्रदान नहीं की जाती है।
यदि आप अपनी गुप्त कुंजी घुमाते हैं, तो उपरोक्त सभी अमान्य हो जाएंगे। गुप्त कुंजी का उपयोग उपयोगकर्ताओं के पासवर्ड के लिए नहीं किया जाता है और कुंजी रोटेशन उन्हें प्रभावित नहीं करेगा।
ध्यान दें
settings.py
द्वारा बनाई गई
डिफ़ॉल्ट
फ़ाइल
सुविधा के लिए
django-admin startproject
एक अद्वितीय बनाता है
SECRET_KEY
।
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_SECONDS
आपकी साइट को तोड़ सकता है।
पहले
HTTP सख्त परिवहन सुरक्षा
दस्तावेज
पढ़ें
।
SECURE_HSTS_PRELOAD
चूक:
False
यदि
True
,
HTTP सख्त परिवहन सुरक्षा
हेडर
SecurityMiddleware
में
preload
निर्देश
जोड़ता है
।
इसका कोई प्रभाव नहीं
है
जब तक कि
यह एक शून्य-शून्य मान पर सेट
न हो
।
SECURE_HSTS_SECONDS
SECURE_HSTS_SECONDS
चूक:
0
यदि एक गैर-शून्य पूर्णांक मान पर
SecurityMiddleware
सेट किया गया है
,
तो
HTTP स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी
हेडर उन सभी प्रतिक्रियाओं पर
सेट करता है जो
पहले से ही नहीं है।
चेतावनी
इसे गलत तरीके से सेट करना अपरिवर्तनीय रूप से (कुछ समय के लिए) आपकी साइट को तोड़ सकता है। पहले 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
।
चेतावनी
यदि आप यह जानने के बिना कि आप क्या कर रहे हैं, तो आप शायद अपनी साइट में सुरक्षा छेद खोलेंगे। और अगर आप इसे सेट करने में विफल रहते हैं जब आपको चाहिए। गंभीरता से।
सुनिश्चित करें कि इसे स्थापित करने से पहले निम्नलिखित में से सभी सत्य हैं (ऊपर दिए गए उदाहरण से मानों को मानते हुए):
- आपका Django ऐप एक प्रॉक्सी के पीछे है।
-
आपका प्रॉक्सी
X-Forwarded-Proto
सभी आने वाले अनुरोधों से हेडर को स्ट्रिप करता है। दूसरे शब्दों में, यदि अंतिम उपयोगकर्ता अपने अनुरोध में उस हेडर को शामिल करते हैं, तो प्रॉक्सी इसे छोड़ देगा। -
आपका प्रॉक्सी
X-Forwarded-Proto
हेडर सेट करता है और इसे Django को भेजता है, लेकिन केवल उन अनुरोधों के लिए जो मूल रूप से HTTPS के माध्यम से आते हैं।
यदि उनमें से कोई भी सत्य नहीं है, तो आपको इस सेटिंग को
None
HTTPS निर्धारित करने का एक और तरीका खोजना
चाहिए
, शायद कस्टम मिडलवेयर के माध्यम से।
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
ध्यान दें
यदि
True
इसे अनन्त रीडायरेक्ट
करने का
कारण बनता है, तो इसका मतलब है कि आपकी साइट प्रॉक्सी के पीछे चल रही है और यह नहीं बता सकती कि कौन से अनुरोध सुरक्षित हैं और कौन से नहीं हैं।
आपकी प्रॉक्सी संभावना सुरक्षित अनुरोधों को इंगित करने के लिए एक हेडर सेट करती है;
आप उस हेडर का पता लगाकर और उसके
SECURE_PROXY_SSL_HEADER
अनुसार सेटिंग को
कॉन्फ़िगर करके समस्या को ठीक कर सकते हैं
।
SERIALIZATION_MODULES
डिफ़ॉल्ट: परिभाषित नहीं है
क्रमबद्ध प्रकार के लिए एक स्ट्रिंग पहचानकर्ता द्वारा कुंजीबद्ध धारावाहिक परिभाषाओं (स्ट्रिंग के रूप में प्रदान) वाले मॉड्यूल का शब्दकोश। उदाहरण के लिए, एक YAML धारावाहिक को परिभाषित करने के लिए, उपयोग करें:
SERIALIZATION_MODULES = {'yaml': 'path.to.yaml_serializer'}
SERVER_EMAIL
चूक:
'[email protected]'
ईमेल संदेश जिसमें त्रुटि संदेश आते हैं, जैसे कि भेजे गए
ADMINS
और
MANAGERS
।
मेरे ईमेल अलग पते से क्यों भेजे गए हैं?
इस पते का उपयोग केवल त्रुटि संदेशों के लिए किया जाता है।
यह
पता
नहीं
है कि नियमित ईमेल संदेश किसके साथ भेजे गए हैं
send_mail()
;
उसके लिए, देखें
DEFAULT_FROM_EMAIL
।
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
चाहे इंजन स्थापित अनुप्रयोगों के अंदर टेम्पलेट स्रोत फ़ाइलों के लिए दिखना चाहिए।
ध्यान दें
सेट
settings.py
द्वारा बनाई गई
डिफ़ॉल्ट
फ़ाइल
।
django-admin startproject
'APP_DIRS': True
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 को पहली बार
TIME_ZONE
सेट के
साथ जारी किया गया था
'America/Chicago'
, इसलिए
बैकवर्ड संगतता के
लिए वैश्विक सेटिंग (यदि कुछ भी आपके प्रोजेक्ट में परिभाषित नहीं है
settings.py
)
का उपयोग किया जाता है
'America/Chicago'
।
नई परियोजना टेम्पलेट्स के लिए डिफ़ॉल्ट
'UTC'
।
ध्यान दें कि यह आवश्यक रूप से सर्वर का समय क्षेत्र नहीं है। उदाहरण के लिए, एक सर्वर कई Django- संचालित साइटों की सेवा कर सकता है, प्रत्येक एक अलग समय क्षेत्र सेटिंग के साथ।
कब
USE_TZ
है
False
, यह समय क्षेत्र है जिसमें Django सभी डेटासेट को संग्रहीत करेगा।
कब
USE_TZ
है
True
, यह डिफ़ॉल्ट समय क्षेत्र है जो Django टेम्पलेट्स में डेटासेट प्रदर्शित करने और रूपों में दर्ज किए गए डेटासेट की व्याख्या करने के लिए उपयोग करेगा।
यूनिक्स वातावरण (जहां
time.tzset()
लागू होता है) पर, Django
os.environ['TZ']
चर को उस समय क्षेत्र में
सेट करता है जिसे
आप
TIME_ZONE
सेटिंग
में निर्दिष्ट करते
हैं।
इस प्रकार, आपके सभी विचार और मॉडल इस समय क्षेत्र में स्वचालित रूप से काम करेंगे।
हालाँकि, Django
TZ
पर्यावरण चर को
सेट नहीं करेगा
यदि आप मैन्युअल कॉन्फ़िगरेशन विकल्प का उपयोग कर रहे हैं जैसा कि
मैन्युअल रूप से सेटिंग में कॉन्फ़िगर
किया गया है
।
यदि Django
TZ
पर्यावरण चर को
सेट नहीं करता है
, तो यह सुनिश्चित करना आपके लिए सही प्रक्रिया में चल रही प्रक्रियाएं हैं।
ध्यान दें
Django विंडोज वातावरण में वैकल्पिक समय क्षेत्रों का उपयोग नहीं कर सकता है।
यदि आप विंडोज पर Django चला रहे हैं,
TIME_ZONE
तो सिस्टम टाइम ज़ोन से मिलान करने के लिए सेट होना चाहिए।
USE_I18N
चूक:
True
एक बूलियन जो निर्दिष्ट करता है कि क्या Django की अनुवाद प्रणाली को सक्षम किया जाना चाहिए।
यह प्रदर्शन के लिए इसे बंद करने का एक आसान तरीका प्रदान करता है।
यदि यह निर्धारित किया जाता है
False
, तो Django कुछ अनुकूलन करेगा ताकि अनुवाद मशीनरी को लोड न किया जा सके।
यह भी देखें
LANGUAGE_CODE
,
USE_L10N
और
USE_TZ
।
ध्यान दें
settings.py
द्वारा बनाई गई
डिफ़ॉल्ट
फ़ाइल
सुविधा के लिए
django-admin startproject
शामिल
USE_I18N = True
है।
USE_L10N
चूक:
False
एक बूलियन जो निर्दिष्ट करता है कि डेटा का स्थानीय स्वरूपण डिफ़ॉल्ट रूप से सक्षम होगा या नहीं।
यदि यह करने के लिए सेट है
True
, जैसे Django वर्तमान स्थान के प्रारूप का उपयोग करके संख्या और दिनांक प्रदर्शित करेगा।
यह भी देखें
LANGUAGE_CODE
,
USE_I18N
और
USE_TZ
।
ध्यान दें
settings.py
द्वारा बनाई गई
डिफ़ॉल्ट
फ़ाइल
सुविधा के लिए
django-admin startproject
शामिल
USE_L10N = True
है।
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
।
ध्यान दें
settings.py
द्वारा बनाई गई
डिफ़ॉल्ट
फ़ाइल
सुविधा के लिए
django-admin startproject
शामिल
USE_TZ = True
है।
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'
उपयोगकर्ता का प्रतिनिधित्व करने के लिए उपयोग करने के लिए मॉडल। एक कस्टम उपयोगकर्ता मॉडल को प्रतिस्थापित करना देखें ।
चेतावनी
आप गंभीर प्रयास के बिना किसी प्रोजेक्ट के जीवनकाल के दौरान AUTH_USER_MODEL सेटिंग को नहीं बदल सकते (यानी एक बार जब आप इसे बना और माइग्रेट किए गए मॉडल पर निर्भर करते हैं) यह परियोजना के शुरू होने पर सेट होने का इरादा है, और यह जिस मॉडल को संदर्भित करता है उसे ऐप के पहले माइग्रेशन में उपलब्ध होना चाहिए। यह अधिक विवरण के लिए एक कस्टम उपयोगकर्ता मॉडल को प्रतिस्थापित करता है ।
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
संदेश फ्रेमवर्क द्वारा रिकॉर्ड किए जाने वाले न्यूनतम संदेश स्तर को सेट करता है। देखें संदेश स्तरों अधिक जानकारी के लिए।
जरूरी
यदि आप
MESSAGE_LEVEL
अपनी सेटिंग फ़ाइल में
ओवरराइड
करते हैं और किसी भी अंतर्निहित स्थिरांक पर भरोसा करते हैं, तो आपको परिपत्र आयात की क्षमता से बचने के लिए स्थिरांक मॉड्यूल को सीधे आयात करना होगा, जैसे:
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 वर्ग के रूप में प्रस्तुत किया जाता है। यदि आप कोई मान निर्दिष्ट करते हैं, तो यह डिफ़ॉल्ट का विस्तार करेगा। इसका मतलब है कि आपको केवल उन मूल्यों को निर्दिष्ट करना होगा जिन्हें आपको ओवरराइड करने की आवश्यकता है। अधिक विवरण के लिए ऊपर संदेश प्रदर्शित करना देखें ।
जरूरी
यदि आप
MESSAGE_TAGS
अपनी सेटिंग फ़ाइल में
ओवरराइड
करते हैं और किसी भी अंतर्निहित स्थिरांक पर भरोसा करते हैं, तो आपको
constants
परिपत्र आयात की क्षमता से बचने के लिए मॉड्यूल को सीधे
आयात करना होगा
, जैसे:
from django.contrib.messages import constants as message_constants MESSAGE_TAGS = {message_constants.INFO: ''}
यदि वांछित है, तो आप उपरोक्त स्थिरांक तालिका के मानों के अनुसार स्थिरांक के लिए सीधे संख्यात्मक मान निर्दिष्ट कर सकते हैं ।
सत्र
के लिए सेटिंग्स
django.contrib.sessions
।
SESSION_CACHE_ALIAS
चूक:
'default'
यदि आप कैश-आधारित सत्र संग्रहण का उपयोग कर रहे हैं , तो यह उपयोग करने के लिए कैश का चयन करता है।
SESSION_COOKIE_AGE
सत्र कुकीज़ की आयु, सेकंड में।
SESSION_COOKIE_DOMAIN
सत्र कुकीज़ के लिए उपयोग करने के लिए डोमेन।
इसे एक स्ट्रिंग पर सेट करें जैसे कि
"example.com"
क्रॉस-डोमेन कुकीज़, या
None
मानक डोमेन कुकी के लिए
उपयोग करें
।
उत्पादन साइट पर इस सेटिंग को अपडेट करते समय सतर्क रहें। यदि आप ऐसी सेटिंग को अपडेट करते हैं जो पहले मानक डोमेन कुकीज़ का उपयोग करने वाली साइट पर क्रॉस-डोमेन कुकीज़ को सक्षम करने के लिए, मौजूदा उपयोगकर्ता कुकीज़ पुराने डोमेन पर सेट की जाएगी। जब तक ये कुकीज़ बनी रहती हैं, तब तक यह लॉग इन करने में असमर्थ हो सकता है।
यह सेटिंग द्वारा निर्धारित कुकीज़ को भी प्रभावित करती है
django.contrib.messages
।
SESSION_COOKIE_HTTPONLY
HTTPOnly
सत्र कुकी पर ध्वज
का उपयोग करना है या नहीं
।
यदि यह सेट हो जाता है
True
, तो क्लाइंट-साइड जावास्क्रिप्ट सत्र कुकी तक पहुंचने में सक्षम नहीं होगा।
HTTPOnly एक ध्वज है जो सेट-कुकी HTTP प्रतिक्रिया शीर्षलेख में शामिल है। यह कुकीज़ के लिए RFC 2109 मानक का हिस्सा नहीं है , और यह सभी ब्राउज़रों द्वारा लगातार सम्मानित नहीं किया जाता है। हालाँकि, जब इसे सम्मानित किया जाता है, तो यह सुरक्षित कुकी डेटा तक पहुँचने वाले क्लाइंट साइड स्क्रिप्ट के जोखिम को कम करने का एक उपयोगी तरीका हो सकता है।
इसे चालू करना किसी हमलावर के लिए उपयोगकर्ता के सत्र के पूर्ण अपहरण में क्रॉस-साइट स्क्रिप्टिंग भेद्यता को बढ़ाने के लिए कम तुच्छ बनाता है। इसे छोड़ने के लिए कोई बहाना नहीं है, या तो: यदि आपका कोड जावास्क्रिप्ट से सत्र कुकीज़ को पढ़ने पर निर्भर करता है, तो आप शायद इसे गलत कर रहे हैं।
SESSION_COOKIE_NAME
सत्र के लिए उपयोग करने के लिए कुकी का नाम। यह वह हो सकता है जो आप चाहते हैं (जब तक यह आपके आवेदन में अन्य कुकी नामों से अलग है)।
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
सत्र कुकी के लिए सुरक्षित कुकी का उपयोग करना है या नहीं।
यदि इसे सेट किया जाता है
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
प्रबंधन कमांड इस डायरेक्टरी में स्टैटिक फाइल्स एकत्रित करेगा।
उपयोग के बारे में अधिक जानकारी के लिए
स्थैतिक फ़ाइलों
को
प्रबंधित
करने का तरीका देखें
।
चेतावनी
तैनाती के आसानी के लिए अपने स्थाई स्थानों से अपनी स्थाई फाइलों को एक निर्देशिका में एकत्रित करने के लिए यह एक प्रारंभिक रूप से खाली गंतव्य निर्देशिका होनी चाहिए;
यह
आपकी स्थैतिक फ़ाइलों को स्थायी रूप से संग्रहीत करने का स्थान
नहीं
है।
कि निर्देशिका से मिल जाएगा कि में आपको क्या करना चाहिए
staticfiles
की
STATICFILES_FINDERS
, जो डिफ़ॉल्ट रूप से, कर रहे हैं
'static/'
एप्लिकेशन उप-निर्देशिका और किसी भी निर्देशिका आप में शामिल
STATICFILES_DIRS
)।
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
सेटिंग
द्वारा परिभाषित डिफ़ॉल्ट फ़ाइल संग्रहण में स्थिर फ़ाइलों के लिए दिखेगा
।
ध्यान दें
AppDirectoriesFinder
खोजक
का उपयोग करते समय
, सुनिश्चित करें कि आपके एप्लिकेशन को स्टेटिकफाइल्स द्वारा पाया जा सकता है।
बस
INSTALLED_APPS
अपनी साइट
की
सेटिंग में
एप्लिकेशन जोड़ें
।
स्टेटिक फ़ाइल फ़ाइंडर्स को वर्तमान में एक निजी इंटरफ़ेस माना जाता है, और यह इंटरफ़ेस इस प्रकार अनिर्दिष्ट है।
कोर सेटिंग्स सामयिक सूचकांक
कैश
डेटाबेस
डिबगिंग
ईमेल
-
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_FILE_STORAGE
-
FILE_CHARSET
-
FILE_UPLOAD_HANDLERS
-
FILE_UPLOAD_MAX_MEMORY_SIZE
-
FILE_UPLOAD_PERMISSIONS
-
FILE_UPLOAD_TEMP_DIR
-
MEDIA_ROOT
-
MEDIA_URL
फार्म
वैश्वीकरण (
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
- सुरक्षा
-
SIGNING_BACKEND
-
USE_X_FORWARDED_HOST
-
USE_X_FORWARDED_PORT
-
WSGI_APPLICATION
लॉगिंग
मॉडल के
सुरक्षा
- क्रॉस साइट अनुरोध सुरक्षा संरक्षण
-
SECRET_KEY
-
X_FRAME_OPTIONS
क्रमबद्धता
टेम्पलेट्स
परिक्षण
-
डेटाबेस:
TEST
-
TEST_NON_SERIALIZED_APPS
-
TEST_RUNNER
यूआरएल
