サイトを公開している場合、DEBUG 設定は常にオフにしておかなければなりません。これにより、サーバー動作は高速になり、エラーページによって明らかになるアプリケーションの詳細が悪意あるユーザーに漏れるのを防ぎます。
しかし、 DEBUG を False にセットして実行すると、サイトによって生成されるエラーが見られなくなります――表示されるのは万人向けのエラーページだけです。そこで、本番サイトで起きたエラーを追跡するために、Django ではこれらのエラーに関する詳細なレポートを作成するように設定できます。
DEBUG が False であるとき、コードがハンドリングされない例外を起こして内部サーバーエラーが起きると (厳密には、500 以上の HTTP ステータスコードを持つ全てのレスポンスが返ってくると)、Django は ADMINS 設定のリストに含まれるユーザーにメールを送信します。これにより、管理者はすぐにエラーの通知を受け取ることができます。メールには、ADMINS はエラーの説明、Python のトレースバック全体、エラーを引き起こした HTTP リクエストの詳細について書かれています。
デフォルトでは、 Django は root@localhost からメールを送信します。しかし、メールプロバイダによっては、このアドレスからのメールを全て拒否します。別の送信者アドレスを使うには、 SERVER_EMAIL 設定を変更してください。
この動作を有効にするには、受信者のメールアドレスを ADMINS 設定に含めます。
Django は、リンク切れに関するエラー (404 "page not found" エラー) をメールで送信するように設定することもできます。Django は以下の場合に 404 エラーに関するメールを送ります:
\nDEBUG が False のとき;
MIDDLEWARE 設定に django.middleware.common.BrokenLinkEmailsMiddleware が含まれているとき。
これらの条件が満たされると、Django はあなたのコードが 404 を発生させ、そのリクエストがリファラを持っている場合、 MANAGERS 設定にリストされているユーザにメールを送ります。リファラを持たない 404 にはわざわざメールを送りません。それは大抵、壊れた URL を入力したユーザか、壊れた Web ボットです。また、リファラがリクエストされた URL と同じ場合の 404 も無視します。
特定の 404 を報告しないように Django に指示するには、 IGNORABLE_404_URLS 設定をいじります。これはコンパイルされた正規表現オブジェクトのリストでなければなりません。例えば:
import re\n\nIGNORABLE_404_URLS = [\n re.compile(r"\\.(php|cgi)$"),\n re.compile(r"^/phpmyadmin/"),\n]\nこの例では、 .php または .cgi で終わる URL への 404 は報告されません。また、 /phpmyadmin/ で始まるURLも報告されません。
以下は、ブラウザやクローラがよくリクエストする従来の URL を除外する方法の例です:
\nimport re\n\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(これらは正規表現なので、ピリオドの前にバックスラッシュを入れてエスケープしていることに注意してください)
\ndjango.middleware.common.BrokenLinkEmailsMiddleware の動作をさらにカスタマイズしたい場合(例えば、ウェブクローラからのリクエストを無視したい場合など)は、サブクラスを作成し、そのメソッドをオーバーライドしてください。
エラーレポートはエラーのデバッグにとても役立つので、通常は、エラーに関する関連情報をできるだけ多く記録しておくと便利です。例えば、デフォルトでは Django は発生した例外の full traceback や、各 traceback frame のローカル変数、 HttpRequest の 属性 を記録します。
しかし、例えばユーザのパスワードやクレジットカード番号のように、ある種の情報は機密性が高すぎるため、記録するのが適切でない場合があります。そこで Django では、 DEBUG ドキュメントで説明されているように、機密性が高そうな設定をフィルタリングすることに加えて、本番環境 (つまり、 DEBUG が False に設定されている場合) でエラーレポートからフィルタリングされる情報を制御するのに役立つ関数デコレータを提供しています。 sensitive_variables() と sensitive_post_parameters() です。
コード内の関数（ビューまたは通常のコールバック）が機密情報を含む可能性のあるローカル変数を使用している場合、 sensitive_variables デコレータを使用することで、それらの変数の値がエラーレポートに含まれないようにすることができます:
from django.views.decorators.debug import sensitive_variables\n\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 ...\n上記の例では、 user、pw、cc の値は非表示になり、エラーレポートではアスタリスク (*******) に置き換えられますが、 name 変数の値は公開されます。
関数のすべてのローカル変数をエラーログから徹底的に隠す場合は、引数なしで sensitive_variables デコレーターを使います:
@sensitive_variables()\ndef my_function(): ...\nもしビューの 1 つが HttpRequest オブジェクトを POST parameters で受け取った場合、機密情報が含まれている可能性があるので、 sensitive_post_parameters デコレータを使って、エラーレポートにそのパラメータの値が含まれないようにすることができます:
from django.views.decorators.debug import sensitive_post_parameters\n\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 ...\n上の例では、 pass_word と credit_card_number のPOSTパラメータの値は隠され、エラーレポート内のリクエストの表現ではアスタリスク (*******) に置き換えられますが、 name パラメータの値は公開されます。
エラーレポートでリクエストの全てのPOSTパラメータを徹底的に隠す場合は、 引数なしで sensitive_post_parameters デコレータを使います:
@sensitive_post_parameters()\ndef my_view(request): ...\n特定の django.contrib.auth.views のビュー (auth admin 内の login, password_reset_confirm, password_change, auth admin の add_view と user_change_password) のエラーレポートから、すべての POST パラメータが徹底的にフィルタされ、ユーザパスワードのような機密情報の漏洩を防ぎます。
sensitive_variables() と sensitive_post_parameters() がすることは、それぞれ、装飾された関数にセンシティブな変数名をアノテートし、HttpRequest オブジェクトにセンシティブな POST パラメータ名をアノテートするだけです。実際のフィルタリングは Django のデフォルトのエラーレポートフィルタ ( django.views.debug.SafeExceptionReporterFilter ) で行われます。このフィルタはデコレータのアノテーションを使い、エラーレポートが生成される際に、対応する値をアスタリスク (*******) に置き換えます。このデフォルトの動作を上書きしたり、サイト全体でカスタマイズしたい場合は、独自のフィルタクラスを定義し、 DEFAULT_EXCEPTION_REPORTER_FILTER 設定でそれを使うように Django に指示する必要があります:
DEFAULT_EXCEPTION_REPORTER_FILTER = "path.to.your.CustomExceptionReporterFilter"\nまた、 HttpRequest の exception_reporter_filter 属性を指定することで、任意のビューで使用するフィルタをより細かく制御できます:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nカスタムフィルタクラスは django.views.debug.SafeExceptionReporterFilter を継承し、以下の属性とメソッドをオーバーライドする必要があります:
センシティブな値を置換する文字列値。デフォルトでは、センシティブな変数の値をアスタリスク (*******) で置き換えます。
センシティブな設定や request.META にマッチする正規表現オブジェクト。デフォルトでは下記です:
import re\n\nre.compile(r"API|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)\nget_post_parameters() と get_traceback_frame_variables() のフィルタリングを有効にする場合は True を返します。デフォルトでは DEBUG が False の場合に有効になります。 DEBUG のドキュメントにあるように、センシティブな request.META の値は常に、センシティブな設定値とともにフィルタリングされることに注意してください。
フィルタリングされた POST パラメータの辞書を返します。センシティブな値は cleansed_substitute で置換されます。
与えられたトレースバックフレームのローカル変数のフィルタリングされた辞書を返します。センシティブな値は cleansed_substitute で置き換えられます。
フィルタリングの他にエラーレポートをカスタマイズする必要がある場合は、 DEFAULT_EXCEPTION_REPORTER 設定を定義することでカスタムエラーレポータークラスを指定できます:
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"\n例外レポーターは例外レポートデータをコンパイルし、テキストまたはHTMLとして適切にフォーマットする責任があります。(例外報告レポーターは、例外レポートデータを作成する際に DEFAULT_EXCEPTION_REPORTER_FILTER を使用します)。
カスタムレポータークラスは django.views.debug.ExceptionReporter を継承する必要があります。
例外の HTML 表現をレンダリングするテンプレートへの絶対ファイルシステムパスを表す pathlib.Path を返すプロパティです。デフォルトは Django が提供するテンプレートです。
pathlib.Path を返すプロパティで、例外のプレーンテキスト表現をレンダリングするテンプレー トへのファイルシステムの絶対パスを表します。デフォルトは Django が提供するテンプレートです。
トレースバック情報を含む辞書を返します。
\nこれは、例えば例外レポートをカスタマイズするための主な拡張ポイントです。例えば下記のようにします:
\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\n例外レポートの HTML 版を返します。
\nデバッグ 500 HTTP エラー・ページの HTML 版に使用されます。
\n例外レポートのプレーンテキスト版を返します。
\nデバッグ 500 HTTP エラーページおよび E メールレポートのプレーンテキスト版に使用されます。
\nフィルタクラスと同様に、 HttpRequest の exception_reporter_class 属性を指定することで、任意のビューで使用する例外レポータークラスを制御できます:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_class = CustomExceptionReporter()\n ...\n