Django 2.1 - Error reporting

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




django

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

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

हालाँकि, False तरीके से DEBUG साथ चलने का मतलब है कि आप कभी भी अपनी साइट से उत्पन्न त्रुटियों को नहीं देखेंगे - हर कोई आपके सार्वजनिक त्रुटि पृष्ठों को देखेगा। आपको तैनात साइटों में होने वाली त्रुटियों पर नज़र रखने की आवश्यकता है, इसलिए Django को उन त्रुटियों के बारे में विवरण के साथ रिपोर्ट बनाने के लिए कॉन्फ़िगर किया जा सकता है।

ईमेल रिपोर्ट

सर्वर त्रुटियों

जब DEBUG False , तो Django ADMINS सेटिंग में सूचीबद्ध उपयोगकर्ताओं को ईमेल करेगा जब भी आपका कोड एक ADMINS अपवाद उठाता है और आंतरिक सर्वर त्रुटि (HTTP स्थिति कोड 500) में परिणाम होता है। यह प्रशासकों को किसी भी त्रुटि की तत्काल सूचना देता है। ADMINS में त्रुटि, पूर्ण पायथन ट्रेसबैक का विवरण और HTTP अनुरोध के बारे में विवरण मिलेगा, जो त्रुटि का कारण बना।

ध्यान दें

ईमेल भेजने के लिए, Django को यह बताने के लिए कुछ सेटिंग्स की आवश्यकता होती है कि वह आपके मेल सर्वर से कैसे कनेक्ट हो। बहुत कम से कम, आपको EMAIL_HOST और संभवतः EMAIL_HOST_USER और EMAIL_HOST_PASSWORD निर्दिष्ट करना होगा, हालांकि आपके मेल सर्वर के कॉन्फ़िगरेशन के आधार पर अन्य सेटिंग्स की भी आवश्यकता हो सकती है। ईमेल से संबंधित सेटिंग्स की पूरी सूची के लिए Django सेटिंग्स प्रलेखन से परामर्श करें।

डिफ़ॉल्ट रूप से, Django रूट @ localhost से ईमेल भेजेगा। हालाँकि, कुछ मेल प्रदाता इस पते के सभी ईमेल को अस्वीकार कर देते हैं। किसी भिन्न प्रेषक पते का उपयोग करने के लिए, SERVER_EMAIL सेटिंग को संशोधित करें।

इस व्यवहार को सक्रिय करने के लिए, ADMINS सेटिंग में प्राप्तकर्ताओं के ईमेल पते ADMINS

यह भी देखें

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

404 त्रुटियां

Django भी टूटी हुई लिंक के बारे में ईमेल त्रुटियों को कॉन्फ़िगर किया जा सकता है (404 "पृष्ठ नहीं मिला" त्रुटियों)। Django जब 404 त्रुटियों के बारे में ईमेल भेजता है:

यदि वे स्थितियां पूरी हो जाती हैं, तो Django MANAGERS सेटिंग में सूचीबद्ध उपयोगकर्ताओं को ईमेल करेगा जब भी आपका कोड 404 उठाता है और अनुरोध में एक संदर्भकर्ता होता है। यह 404s के लिए ईमेल करने की जहमत नहीं उठाता है जिसमें एक रेफरर नहीं है - वे आमतौर पर टूटे हुए यूआरएल या टूटे हुए वेब बॉट में टाइप करने वाले लोग होते हैं। यह 404s को भी अनदेखा करता है जब रेफरर अनुरोधित URL के बराबर होता है, क्योंकि यह व्यवहार टूटे हुए वेब बॉट से भी होता है।

ध्यान दें

django.middleware.common.BrokenLinkEmailsMiddleware को अन्य मिडलवेयर से पहले प्रदर्शित होना चाहिए जो 404 त्रुटियों को LocaleMiddleware करता है, जैसे कि LocaleMiddleware या FlatpageFallbackMiddleware । इसे अपने MIDDLEWARE सेटिंग के शीर्ष की ओर रखें।

आप Django को IGNORABLE_404_URLS सेटिंग को IGNORABLE_404_URLS करके विशेष रूप से 404s रिपोर्टिंग बंद करने के लिए कह सकते हैं। यह संकलित नियमित अभिव्यक्ति वस्तुओं की सूची होनी चाहिए। उदाहरण के लिए:

import re
IGNORABLE_404_URLS = [
    re.compile(r'\.(php|cgi)$'),
    re.compile(r'^/phpmyadmin/'),
]

इस उदाहरण में, .php या .cgi साथ समाप्त होने वाले किसी भी URL के लिए 404 की सूचना नहीं दी जाएगी। न ही कोई URL /phpmyadmin/ शुरू होगा।

निम्न उदाहरण दिखाता है कि कुछ पारंपरिक URL जिन्हें ब्राउज़र और क्रॉलर अक्सर अनुरोध करते हैं, को बाहर कैसे करें:

import re
IGNORABLE_404_URLS = [
    re.compile(r'^/apple-touch-icon.*\.png$'),
    re.compile(r'^/favicon\.ico$'),
    re.compile(r'^/robots\.txt$'),
]

(ध्यान दें कि ये नियमित अभिव्यक्तियाँ हैं, इसलिए हम इनसे बचने के लिए पीरियड्स के सामने बैकस्लैश लगाते हैं।)

यदि आप django.middleware.common.BrokenLinkEmailsMiddleware के व्यवहार को और अधिक कस्टमाइज़ करना चाहते हैं (उदाहरण के लिए वेब क्रॉलर से आने वाले अनुरोधों को अनदेखा करना), तो आपको इसे उप-वर्ग करना चाहिए और इसके तरीकों को ओवरराइड करना चाहिए।

यह भी देखें

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

फ़िल्टरिंग त्रुटि रिपोर्ट

चेतावनी

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

संवेदनशील जानकारी को छानना

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

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

sensitive_variables(*variables) [source]

यदि आपके कोड में कोई फ़ंक्शन (या तो कोई नियमित कॉलबैक) संवेदनशील सूचनाओं को रखने के लिए अतिसंवेदनशील स्थानीय चर का उपयोग करता है, तो आप उन चर के मानों को sensitive_variables रिपोर्ट में शामिल होने से रोक सकते हैं जिनमें sensitive_variables डेकोरेटर का उपयोग किया गया है:

from django.views.decorators.debug import sensitive_variables

@sensitive_variables('user', 'pw', 'cc')
def process_info(user):
    pw = user.pass_word
    cc = user.credit_card_number
    name = user.name
    ...

उपरोक्त उदाहरण में, user , pw और cc चर के मानों को छिपाया जाएगा और उन्हें त्रुटि रिपोर्ट में सितारों ( ********** ) से बदल दिया जाएगा, जबकि name चर के मूल्य का खुलासा किया जाएगा।

त्रुटि लॉग से किसी फ़ंक्शन के सभी स्थानीय चर को व्यवस्थित रूप से छिपाने के लिए, sensitive_variables डेकोरेटर को कोई तर्क न दें:

@sensitive_variables()
def my_function():
    ...

कई सज्जाकारों का उपयोग करते समय

यदि आप जिस चर को छिपाना चाहते हैं, वह एक फ़ंक्शन तर्क (उदाहरण के उदाहरण में ' user ') है, और यदि सजाया गया फ़ंक्शन में कई सज्जाकार हैं, तो डेकोरेटर श्रृंखला के शीर्ष पर @sensitive_variables सुनिश्चित करें। इस तरह यह फ़ंक्शन तर्क को भी छिपा देगा क्योंकि यह अन्य सज्जाकारों के माध्यम से पारित हो जाता है:

@sensitive_variables('user', 'pw', 'cc')
@some_decorator
@another_decorator
def process_info(user):
    ...
sensitive_post_parameters(*parameters) [source]

यदि आपके विचारों में से एक में संवेदनशील जानकारी रखने के लिए अतिसंवेदनशील POST parameters साथ एक HttpRequest ऑब्जेक्ट प्राप्त होता है, तो आप उन मापदंडों के मानों को sensitive_post_parameters रिपोर्ट में शामिल होने से रोक सकते हैं जिनमें sensitive_post_parameters post_parameters डेकोरेटर का उपयोग किया गया है:

from django.views.decorators.debug import sensitive_post_parameters

@sensitive_post_parameters('pass_word', 'credit_card_number')
def record_user_profile(request):
    UserProfile.create(
        user=request.user,
        password=request.POST['pass_word'],
        credit_card=request.POST['credit_card_number'],
        name=request.POST['name'],
    )
    ...

उपरोक्त उदाहरण में, pass_word और credit_card_number POST मापदंडों के मानों को त्रुटि रिपोर्ट के अंदर अनुरोध के प्रतिनिधित्व में सितारों ( ********** ) के साथ छिपा दिया जाएगा, जबकि name पैरामीटर का मान होगा खुलासा किया जाए।

त्रुटि रिपोर्ट में अनुरोध के सभी POST मापदंडों को व्यवस्थित रूप से छिपाने के लिए, sensitive_post_parameters post_paramete सजावट के लिए कोई तर्क न दें:

@sensitive_post_parameters()
def my_view(request):
    ...

उपयोगकर्ता के पासवर्ड जैसी संवेदनशील जानकारी को लीक होने से रोकने के लिए सभी POST मापदंडों को निश्चित django.contrib.auth.views विचारों ( login , password_reset_confirm , password_change , और add_view और user_change_password में) के लिए त्रुटि रिपोर्ट से व्यवस्थित रूप से फ़िल्टर किया जाता है।

कस्टम त्रुटि रिपोर्ट

सभी sensitive_variables() और sensitive_post_parameters() क्रमशः संवेदनशील चर के नामों के साथ सजाए गए फ़ंक्शन को HttpRequest करते हैं और संवेदनशील POST मापदंडों के नाम के साथ HttpRequest ऑब्जेक्ट का एनोटेट करते हैं, ताकि बाद में इस संवेदनशील जानकारी को रिपोर्ट से बाहर फ़िल्टर किया जा सके जब त्रुटि होती है। वास्तविक फ़िल्टरिंग Django के डिफ़ॉल्ट त्रुटि रिपोर्टर फ़िल्टर द्वारा किया जाता है: django.views.debug.SafeExceptionReporterFilter । यह फ़िल्टर डेकोरेटर के एनोटेशन का उपयोग करता है ताकि त्रुटि रिपोर्ट उत्पन्न होने पर तारों ( ********** ) के साथ संबंधित मानों को बदल दिया जा सके। यदि आप अपनी संपूर्ण साइट के लिए इस डिफ़ॉल्ट व्यवहार को ओवरराइड या कस्टमाइज़ करना चाहते हैं, तो आपको अपने स्वयं के फ़िल्टर वर्ग को परिभाषित करने और Django को DEFAULT_EXCEPTION_REPORTER_FILTER सेटिंग के माध्यम से इसका उपयोग करने की आवश्यकता है:

DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'

आप अधिक बारीक तरीके से भी नियंत्रण कर सकते हैं, जो HttpRequest के HttpRequest विशेषता को सेट करके किसी भी दृश्य के भीतर उपयोग करने के लिए फ़िल्टर करता है:

def my_view(request):
    if request.user.is_authenticated:
        request.exception_reporter_filter = CustomExceptionReporterFilter()
    ...

आपके कस्टम फ़िल्टर वर्ग को django.views.debug.SafeExceptionReporterFilter से इनहेरिट करने की आवश्यकता है और निम्नलिखित विधियों को ओवरराइड कर सकते हैं:

class SafeExceptionReporterFilter [source]
SafeExceptionReporterFilter.is_active(request) [source]

अन्य तरीकों से संचालित फ़िल्टरिंग को सक्रिय करने के लिए True है। डिफ़ॉल्ट रूप से फ़िल्टर सक्रिय है यदि DEBUG False

SafeExceptionReporterFilter.get_post_parameters(request) [source]

POST मापदंडों के फ़िल्टर किए गए शब्दकोश को लौटाता है। डिफ़ॉल्ट रूप से यह सितारों ( ********** ) के साथ संवेदनशील मापदंडों के मूल्यों को बदलता है।

SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame) [source]

दिए गए ट्रेसबैक फ़्रेम के लिए स्थानीय चर का फ़िल्टर किया गया शब्दकोश देता है। डिफ़ॉल्ट रूप से यह सितारों ( ********** ) के साथ संवेदनशील चर के मूल्यों को बदल देता है।

यह भी देखें

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