Ketika anda sedang menjalankan situs umum anda harus selalu mematikan pengaturan DEBUG. Itu akan membuat peladen anda berjalan lebih cepat, dan juga akan mencegah pengguna hahat dari melihat rincian dari aplikasi anda yang dapat diungkap dengan kesalahan halaman.
However, running with DEBUG set to False means you'll never see\nerrors generated by your site -- everyone will instead see your public error\npages. You need to keep track of errors that occur in deployed sites, so Django\ncan be configured to create reports with details about those errors.
When DEBUG is False, Django will email the users listed in the\nADMINS setting whenever your code raises an unhandled exception and\nresults in an internal server error (strictly speaking, for any response with\nan HTTP status code of 500 or greater). This gives the administrators immediate\nnotification of any errors. The ADMINS will get a description of the\nerror, a complete Python traceback, and details about the HTTP request that\ncaused the error.
Secara awal, Django akan mengirim surel dari root@localhost. Bagaimanapun, beberapa penyedia surat menolak semua surel dari alamat ini. Untuk menggunakan alamat pengirim berbeda, rubah pengaturan SERVER_EMAIL.
Untuk mengaktifkan perilaku ini, masukkan alamat surel dari penerima di bagian ADMINS.
Django juga dapat dikonfirgasi untuk mengirimkan surel kesalahan tentang tautan yang tidak ditemukan (404 "page not found" errors). Django mengirim surel tentang error 404 ketika:
\nDEBUG adalah False;
Pengaturan MIDDLEWARE anda termasuk django.middleware.common.BrokenLinkEmailsMiddleware.
If those conditions are met, Django will email the users listed in the\nMANAGERS setting whenever your code raises a 404 and the request has\na referer. It doesn't bother to email for 404s that don't have a referer --\nthose are usually people typing in broken URLs or broken Web bots. It also\nignores 404s when the referer is equal to the requested URL, since this\nbehavior is from broken Web bots too.
Anda dapat memberitahu Django untuk menghentikan pelaporan tertentu 404 dengan merubah pengaturan IGNORABLE_404_URLS. Dia harus menjadi daftar dari obyek ungkapan biasa tersusun. Sebagai contoh:
import re\nIGNORABLE_404_URLS = [\n re.compile(r'\\.(php|cgi)$'),\n re.compile(r'^/phpmyadmin/'),\n]\nDalam contoh ini, sebuah 404 pada setiap URL berakhiran dengan .php atau .cgi akan tidak dilaporkan. Juga tidak akan URL apapun dimulai dengan /phpmyadmin/.
Contoh berikut menunjukkan bagaimana mengeluarkan beberapa URL biasa yang perambah dan penjilat sering diminta:
\nimport re\nIGNORABLE_404_URLS = [\n re.compile(r'^/apple-touch-icon.*\\.png$'),\n re.compile(r'^/favicon\\.ico$'),\n re.compile(r'^/robots\\.txt$'),\n]\n(Perhatikan bahwa ini adalah regular expression, jadi kita tuliskan garis miring terbalik di depan titik untuk melepaskannya)
\nJika anda suka menyesuaikan perilaku dari django.middleware.common.BrokenLinkEmailsMiddleware lebih lanjut (sebagai contoh untuk mengabaikan permintaan datang dari penjilat jaringan), anda harus mensubkelaskannya dan menimpa caranya.
Laporan kesalahan sangat membantu untuk memeriksa kesalahan, jadi dia umumnya berguna untuk merekam informasi terkait tentang kesalahan-kesalahan tersebut sebanyak mungkin. Sebagai contoh, secara awal rekaman Django full traceback untuk dimunculkan pengecualian, setiap variabel lokal full traceback, dan attributes HttpRequest.
Bagaimanapun, terkadang jenis-jenis informasi tertentu mungkin terlalu sensitif dan dengan demikian mungkin tidak sesuai untuk terus melacak, sebagai contoh, sandi pengguna atau angka kartu kredit. Jadi di tambahaan untuk menyaring pengaturan yang muncul menjadi sensitif seperti digambarkan dalam dokumentasi DEBUG, Django menawarkan sekumpulan fungsi penghias untuk membantu anda mengendalikan informasi mana harus disaring dari laporan kesalahan dalam lingkungan produksi (yaitu, dimana DEBUG disetel ke False): sensitive_variables() dan sensitive_post_parameters().
Jika sebuah fungsi (baik sebuah tampilan atau callback umum apapun) dalam kode anda menggunakan variabel lokal rentan mengandung informasi sensitif, anda mungkin mencegah nilai-nilai variabel tersebut dari menjadi disertakan dalam laporan kesalahan menggunakan penghias sensitive_variables:
from django.views.decorators.debug import sensitive_variables\n\n@sensitive_variables('user', 'pw', 'cc')\ndef process_info(user):\n pw = user.pass_word\n cc = user.credit_card_number\n name = user.name\n ...\nIn the above example, the values for the user, pw and cc\nvariables will be hidden and replaced with stars (**********)\nin the error reports, whereas the value of the name variable will be\ndisclosed.
Untuk secara sistematis menyembunyikan semua variabel lokal dari sebuah fungsi dari laporan kesalahan, jangan menyediakan argumen apapun pada decorator sensitive_variables:
@sensitive_variables()\ndef my_function():\n ...\nJika satu dari tampilan anda menerima sebuah obyek HttpRequest dengan POST parameters rentan untuk mengandung informasi sensitif, anda mungkin mencegah nilai-nilai dari parameter tersebut dari menjadi disertakan dalam laporan kesalahan menggunakan penghias sensitive_post_parameters:
from django.views.decorators.debug import sensitive_post_parameters\n\n@sensitive_post_parameters('pass_word', 'credit_card_number')\ndef record_user_profile(request):\n UserProfile.create(\n user=request.user,\n password=request.POST['pass_word'],\n credit_card=request.POST['credit_card_number'],\n name=request.POST['name'],\n )\n ...\nIn the above example, the values for the pass_word and\ncredit_card_number POST parameters will be hidden and replaced with\nstars (**********) in the request's representation inside the\nerror reports, whereas the value of the name parameter will be\ndisclosed.
Untuk secara sistematis menyembunyikan semua parameter POST dari sebuah permintaan dalam laporan kesalahan, jangan menyediakan argumen apapun pada decorator sensitive_variables:
@sensitive_post_parameters()\ndef my_view(request):\n ...\nSemua parameter POST adalah sistematis disaring keluar dari laporan kesalahan untuk tampilan django.contrib.auth.views tertentu (login, password_reset_confirm, password_change, dan add_view dan user_change_password dalam admin auth) untuk mencegah dari pembocoran dari informasi sensitif seperti sandi pengguna.
All sensitive_variables() and sensitive_post_parameters() do is,\nrespectively, annotate the decorated function with the names of sensitive\nvariables and annotate the HttpRequest object with the names of sensitive\nPOST parameters, so that this sensitive information can later be filtered out\nof reports when an error occurs. The actual filtering is done by Django's\ndefault error reporter filter:\ndjango.views.debug.SafeExceptionReporterFilter. This filter uses the\ndecorators' annotations to replace the corresponding values with stars\n(**********) when the error reports are produced. If you wish to\noverride or customize this default behavior for your entire site, you need to\ndefine your own filter class and tell Django to use it via the\nDEFAULT_EXCEPTION_REPORTER_FILTER setting:
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'\nAnda dapat juga mengendalikan cara lebih kecil penyaring mana untuk digunakan dalam tampilan yang diberikan oleh pengaturan atribut exception_reporter_filter HttpRequest:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nYour custom filter class needs to inherit from\ndjango.views.debug.SafeExceptionReporterFilter and may override the\nfollowing attributes and methods:
The string value to replace sensitive value with. By default it\nreplaces the values of sensitive variables with stars\n(**********).
A compiled regular expression object used to match settings and\nrequest.META values considered as sensitive. By default equivalent\nto:
import re\n\nre.compile(r'API|TOKEN|KEY|SECRET|PASS|SIGNATURE', flags=re.IGNORECASE)\nReturns True to activate the filtering in\nget_post_parameters() and get_traceback_frame_variables().\nBy default the filter is active if DEBUG is False. Note\nthat sensitive request.META values are always filtered along with\nsensitive setting values, as described in the DEBUG\ndocumentation.
Returns the filtered dictionary of POST parameters. Sensitive values\nare replaced with cleansed_substitute.
Returns the filtered dictionary of local variables for the given\ntraceback frame. Sensitive values are replaced with\ncleansed_substitute.
If you need to customize error reports beyond filtering you may specify a\ncustom error reporter class by defining the\nDEFAULT_EXCEPTION_REPORTER setting:
DEFAULT_EXCEPTION_REPORTER = 'path.to.your.CustomExceptionReporter'\nThe exception reporter is responsible for compiling the exception report data,\nand formatting it as text or HTML appropriately. (The exception reporter uses\nDEFAULT_EXCEPTION_REPORTER_FILTER when preparing the exception\nreport data.)
Your custom reporter class needs to inherit from\ndjango.views.debug.ExceptionReporter.
Return a dictionary containing traceback information.
\nThis is the main extension point for customizing exception reports, for\nexample:
\nfrom django.views.debug import ExceptionReporter\n\n\nclass CustomExceptionReporter(ExceptionReporter):\n def get_traceback_data(self):\n data = super().get_traceback_data()\n # ... remove/add something here ...\n return data\nReturn HTML version of exception report.
\nUsed for HTML version of debug 500 HTTP error page.
\nReturn plain text version of exception report.
\nUsed for plain text version of debug 500 HTTP error page and email\nreports.
\nAs with the filter class, you may control which exception reporter class to use\nwithin any given view by setting the HttpRequest’s\nexception_reporter_class attribute:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_class = CustomExceptionReporter()\n ...\n