ここでは、Django の core で利用できる設定とそのデフォルト値をリストしました。contrib アプリで提供される設定のリストは、core の設定のトピックのインデックスの下にあります。入門的な資料については、 settings のトピックガイド を参照してください。
\nABSOLUTE_URL_OVERRIDESLink to this heading#デフォルト値: {} (空の辞書)
"app_label.model_name" 文字列をモデルオブジェクトを受け取り、その URL を返す関数へのマッピングを行う辞書です。これは、インストールごとに get_absolute_url() メソッドを挿入またはオーバーライドする方法です。例：
ABSOLUTE_URL_OVERRIDES = {\n "blogs.blog": lambda o: "/blogs/%s/" % o.slug,\n "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),\n}\nこの設定で使用するモデル名は、実際のモデルクラス名の大文字小文字に関わらず、すべて小文字である必要があります。
\nADMINSLink to this heading#デフォルト値: [] (空のリスト)
コードエラー通知を受け取る全ての人々のリストです。 DEBUG=False が設定され、 AdminEmailHandler が LOGGING に設定されている場合（デフォルトで設定されています）、Djangoはこれらの人々にリクエスト/レスポンスサイクルで発生した例外の詳細をメールで送信します。
Each item in the list should be an email address string. Example:
\nADMINS = ["john@example.com", '"Ng, Mary" <mary@example.com>']\nTo safely build an address with a display name from variable content, see\nFormatting email addresses, which recommends using\nAddress over string formatting, but since this\nsetting requires a list of strings, wrap each Address in str(...).
ALLOWED_HOSTSLink to this heading#デフォルト値: [] (空のリスト)
Django サイトを配信できるホスト/ドメイン名を表す文字列のリストです。これはセキュリティ対策の手段の1つで、一見安全な設定の Web サーバでも晒される可能性が高い、 HTTP Host header 攻撃 を防ぐことができます。
\nこのリスト中の値は完全修飾名 (fully qualified names) (例: 'www.example.com') でも大丈夫です。その場合には、リクエストの Host ヘッダに完全一致するかチェックされます (ポートを含まない、大文字小文字を無視した比較になります)。ピリオドで始まる値は、サブドメインのワイルドカードとして利用できます。たとえば、'.example.com' は example.com や www.example.com などの他のすべての example.com サブドメインにマッチします。'*' という値はあらゆるヘッダにマッチします。この場合には、責任を持って自前の Host ヘッダ検証機 (おそらくミドルウェアの形になり、その場合は MIDDLEWARE 設定の最初に置く必要があります) を書かなければなりません。
Django はあらゆるエントリで fully qualified domain name (FQDN) を許可しています。ブラウザの中には Host ヘッダの最後にドットを付けるもありますが、Django は host の検証機でそれを取り除きます。
If the Host header (or X-Forwarded-Host if\nUSE_X_FORWARDED_HOST is enabled) does not match any value in this\nlist, the django.http.HttpRequest.get_host() method will raise\nSuspiciousOperation.
DEBUG が True であり、かつ ALLOWED_HOSTS が空の場合、ホストは ['.localhost', '127.0.0.1', '[::1]'] に対して検証されます。
ALLOWED_HOSTS は、テストを実行する際にも チェックされます 。
This validation only applies via get_host();\nif your code accesses the Host header directly from request.META you\nare bypassing this security protection.
APPEND_SLASHLink to this heading#デフォルト値: True
True に設定すると、リクエスト URL が URLconf 内のどのパターンにもマッチせず、/ で終わっていなかった場合に、末尾に / を追加した URL への HTTP リダイレクトを発行します。ただし、リダイレクトすると POST リクエストで送信するデータが失われることがあるので注意が必要です。
APPEND_SLASH 設定は CommonMiddleware がインストールされているときのみ有効です。詳しくは see ミドルウェア (Middleware) を参照。また PREPEND_WWW も参照してください。
CACHESLink to this heading#デフォルト値:
\n{\n "default": {\n "BACKEND": "django.core.cache.backends.locmem.LocMemCache",\n }\n}\nDjango で使用されるすべてのキャッシュの設定を含む辞書です。これは、キャッシュのエイリアスを個々のキャッシュのオプションを含む辞書にマッピングする内容のネストされた辞書です。
\nCACHES 設定では、default キャッシュを設定する必要があります。追加で任意の数のキャッシュを指定することもできます。ローカルメモリキャッシュ以外のキャッシュバックエンドを使用する場合、または複数のキャッシュを定義する必要がある場合は、他のオプションが必要になります。以下のキャッシュオプションが利用可能です。
BACKENDLink to this heading#デフォルト値: '' (空文字列)
使用するキャッシュ用バックエンド。ビルトインのキャッシュ用バックエンドには、次のものがあります。
\n'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.PyMemcacheCache'
'django.core.cache.backends.memcached.PyLibMCCache'
'django.core.cache.backends.redis.RedisCache'
Django に同梱されていないキャッシュ用バックエンドを使用する時は、BACKEND にバックエンドのクラスの完全修飾パス (例: mypackage.backends.whatever.WhateverCache) を設定してください。
KEY_FUNCTIONLink to this heading#A string containing a dotted path to a function (or any callable) that defines\nhow to compose a key, prefix, and version into a final cache key. The default\nfunction converts the components to strings and joins them with colons, as\nshown in the cache documentation.
\n好きなキー関数を使用できますが、同じ引数のシグネチャを持つことが条件です。
\nKEY_PREFIXLink to this heading#デフォルト値: '' (空文字列)
Djangoサーバーで使用されるすべてのキャッシュキーにデフォルトで自動的に追加（先頭に付けられる）される文字列。
\n詳細は キャッシュのドキュメント を参照してください。
\nLOCATIONLink to this heading#デフォルト値: '' (空文字列)
使用するキャッシュの位置。これはファイルシステムキャッシュ用のディレクトリ、memcacheサーバーのホストとポート、またはローカルメモリキャッシュの識別名などが該当します。例:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n }\n}\nOPTIONSLink to this heading#デフォルト値: None
キャッシュバックエンドに渡す追加パラメータ。利用可能なパラメータは、使用しているキャッシュバックエンドによって異なります。
\n利用可能なパラメータに関する情報は、 キャッシュ式数 のドキュメントに記載されています。詳細については、バックエンドモジュールの独自のドキュメントを参照してください。
\nTIMEOUTLink to this heading#デフォルト値: 300
キャッシュエントリが古いとみなされるまでの秒数。この設定の値が None である場合、キャッシュエントリは期限切れになりません。値が 0 の場合、キーは即座に期限切れになります（実質的に「キャッシュしない」）。
VERSIONLink to this heading#デフォルト値: 1
Django サーバーによって生成されるキャッシュキーのデフォルトのバージョン番号。
\n詳細は キャッシュのドキュメント を参照してください。
\nCACHE_MIDDLEWARE_ALIASLink to this heading#デフォルト値: 'default'
キャッシュミドルウェア に使用するキャッシュ接続。
\nCACHE_MIDDLEWARE_KEY_PREFIXLink to this heading#デフォルト値: '' (空文字列)
キャッシュキーの生成時に キャッシュミドルウェア からプレフィックスとして追加される文字列です。このプレフィックスは KEY_PREFIX 設定と組み合わされます。それを置き換えるものではありません。
Django のキャッシュフレームワーク を参照。
\nCACHE_MIDDLEWARE_SECONDSLink to this heading#デフォルト値: 600
キャッシュミドルウェア 用のページをキャッシュするデフォルトの秒数。
\nDjango のキャッシュフレームワーク を参照。
\nCSRF_USE_SESSIONSLink to this heading#デフォルト値: False
ユーザーのセッション内にCSRFトークンをCookieではなく保存するかどうか。これを使用するには、 django.contrib.sessions の使用が必要です。
CSRF トークンをクッキーに保存する（Django のデフォルト）は安全ですが、他のウェブフレームワークではセッションに保存することが一般的であり、そのためセキュリティ監査員によってしばしば要求されます。
\nデフォルトのエラービュー が CSRF トークンを必要とするため、CSRF_USE_SESSIONS を使用している場合、エラービューをトリガーする可能性のある例外（例えば PermissionDenied など）を引き起こす可能性があるミドルウェアよりも前に、 SessionMiddleware が MIDDLEWARE に登録されている必要があります。 Middleware の順序 を参照してください。
CSRF_FAILURE_VIEWLink to this heading#デフォルト値: 'django.views.csrf.csrf_failure'
CSRF保護 によって受信リクエストが拒否された場合に使用されるビュー関数へのドット区切りパス。関数には次のシグネチャが必要です:
\ndef csrf_failure(request, reason=""): ...\nreason は、リクエストが拒否された理由を示す短いメッセージ（開発者やログ用であり、エンドユーザー向けではありません）です。これは HttpResponseForbidden を返すべきです。
django.views.csrf.csrf_failure() は追加の template_name パラメータを受け付け、デフォルトでは '403_csrf.html' になっています。その名前のテンプレートが存在する場合、ページのレンダリングに使用されます。
CSRF_HEADER_NAMELink to this heading#デフォルト値: 'HTTP_X_CSRFTOKEN'
CSRF認証に使用されるリクエストヘッダーの名前。
\nrequest.META の他の HTTP ヘッダと同様に、サーバーから受信したヘッダ名は、すべての文字を大文字に変換し、ハイフンをアンダースコアに置き換え、名前に 'HTTP_' プレフィックスを追加することで正規化されます。たとえば、クライアントが 'X-XSRF-TOKEN' ヘッダを送信する場合、設定は 'HTTP_X_XSRF_TOKEN' であるべきです。
CSRF_TRUSTED_ORIGINSLink to this heading#デフォルト値: [] (空のリスト)
安全でないリクエスト (例: POST) のための信頼できるオリジンのリスト。
Origin ヘッダーを含むリクエストに対して、Django の CSRF 保護は、そのヘッダーが Host ヘッダーに存在するオリジンと一致することを要求します。
For a secure (determined by is_secure()) unsafe\nrequest that doesn't include the Origin header, the request must include a\nReferer header that matches the origin in the Host header.
これらのチェックは、例えば、subdomain.example.com からの POST リクエストが api.example.com に対して成功するのを防ぎます。クロスオリジンで安全でないリクエストが必要な場合、例を続けると、このリストに 'https://subdomain.example.com' を追加してください（そして、リクエストが安全でないページから発生する場合は http://... も追加します）。
この設定はサブドメインもサポートしているので、例えば 'https://*.example.com' を追加することで、example.com の全サブドメインからのアクセスを許可できます。
DATABASESLink to this heading#デフォルト値: {} (空の辞書)
Django で使用される全てのデータベースの設定を含む辞書です。これは、データベースエイリアスを個々のデータベースのオプションを含む辞書にマッピングする内容のネストされた辞書です。
\nDATABASES 設定では、default データベースを設定する必要があります。追加で任意の数のデータベースを指定することもできます。
最もシンプルな設定ファイルは、SQLite を使用した単一データベース設定です。これは以下のように設定できます。
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.sqlite3",\n "NAME": "mydatabase",\n }\n}\nMariaDB、MySQL、Oracle、または PostgreSQL などの他のデータベースバックエンドに接続する場合、追加の接続パラメータが必要になります。他のデータベースタイプを指定する方法については、以下の ENGINE 設定を参照してください。この例は PostgreSQL 用です:
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "NAME": "mydatabase",\n "USER": "mydatabaseuser",\n "PASSWORD": "mypassword",\n "HOST": "127.0.0.1",\n "PORT": "5432",\n }\n}\nより複雑な設定に必要な次の内部オプションが利用可能です:
\nATOMIC_REQUESTSLink to this heading#デフォルト値: False
これを True に設定すると、このデータベース上の各ビューをトランザクションでラップします。HTTP リクエストにトランザクションを結びつける を参照してください。
AUTOCOMMITLink to this heading#デフォルト値: True
これを False に設定すると、 Djangoのトランザクション管理を無効にして 、独自のトランザクション管理を実装したい場合に利用できます。
ENGINELink to this heading#デフォルト値: '' (空文字列)
使用するデータベースバックエンドです。組み込みのデータベースバックエンドは次の通りです:
\n'django.db.backends.postgresql'
'django.db.backends.mysql'
'django.db.backends.sqlite3'
'django.db.backends.oracle'
Django に同梱されていないデータベースバックエンドを使用するには、ENGINE を完全修飾パス (例: mypackage.backends.whatever) に設定します。
HOSTLink to this heading#デフォルト値: '' (空文字列)
データベースに接続する際に使用するホストです。空の文字列の場合は localhost を意味します。SQLite では使用されません。
\nこの値がスラッシュ ('/') で始まり、MySQL を使用している場合、MySQL は指定されたソケットに Unix ソケット経由で接続します。例えば:
"HOST": "/var/run/mysql"\nMySQLを使用している場合、この値がスラッシュで 始まらない 場合、この値はホストとみなされます。
\nPostgreSQL を使用している場合、デフォルトでは (HOST が空の場合)、UNIXドメインソケット (pg_hba.conf の 'local' 行) を通じてデータベースに接続されます。UNIXドメインソケットが標準の場所にない場合は、postgresql.conf の unix_socket_directory の値と同じ値を使用してください。TCPソケットを通じて接続したい場合は、HOST を 'localhost' または '127.0.0.1' (pg_hba.conf の 'host' 行) に設定してください。Windows では、UNIXドメインソケットが利用できないため、常に HOST を定義する必要があります。
NAMELink to this heading#デフォルト値: '' (空文字列)
使用するデータベースの名前。SQLite の場合、データベースファイルへのフルパスになります。パスを指定する場合は、Windows であっても常にスラッシュを使用してください（例: C:/homes/user/mysite/sqlite3.db ）。
CONN_MAX_AGELink to this heading#デフォルト値: 0
データベース接続の寿命を秒単位の整数で指定します。各リクエストの終了時にデータベース接続を閉じる場合は 0 を使用します（Django の従来の動作）。無制限の 永続的なデータベース接続 の場合は None を使用します。
CONN_HEALTH_CHECKSLink to this heading#デフォルト値: False
もし True に設定されている場合、データベースアクセスを行う各リクエストで再利用される前に、既存の 永続的なデータベース接続 がヘルスチェックされます。ヘルスチェックが失敗した場合、接続は再確立され、データベースサーバーは新しい接続を受け入れ、提供する準備が整っているが、接続が使用できなくなったときにリクエストが失敗することはありません（例：データベースサーバーが再起動し、既存の接続を閉じた後）。
OPTIONSLink to this heading#デフォルト値: {} (空の辞書)
データベースに接続する際に使用する追加パラメータ。利用可能なパラメータは、使用しているデータベースバックエンドによって異なります。
\n利用可能なパラメータに関する情報は、 データベースのバックエンド のドキュメントに記載されています。詳細については、バックエンドモジュール独自のドキュメントを参照してください。
\nPASSWORDLink to this heading#デフォルト値: '' (空文字列)
データベースに接続する際に使用するパスワード。SQLiteでは使用しません。
\nPORTLink to this heading#デフォルト値: '' (空文字列)
データベースに接続する際に使用するポート。空の文字列はデフォルトポートを意味します。SQLiteでは使用されません。
\nTIME_ZONELink to this heading#デフォルト値: None
このデータベース接続のためのタイムゾーンを表す文字列、または None です。 DATABASES 設定のこの内部オプションは、一般的な TIME_ZONE 設定と同じ値を受け付けます。
USE_TZ が True のとき、データベースからの日時の読み込みは、タイムゾーンが None ではない場合はその値に、そうでない場合は UTC に設定された意識的な日時を返します。
USE_TZ が False の場合、このオプションを設定するとはエラーになります。
データベースバックエンドがタイムゾーンをサポートしていない場合（例えば SQLite、MySQL、Oracle など）、このオプションが設定されている場合は Django はローカルタイムで日時を読み書きし、設定されていない場合は UTC で行います。
\n接続のタイムゾーンを変更すると、データベースの読み書きに影響が出ます。
\nDjango がデータベースを管理しており、別の強い理由がない限り、このオプションを設定しないでおくべきです。UTC で日時を保存することが最善です。これにより、サマータイムの変更時に曖昧な日時や存在しない日時を回避できます。また、UTC で日時を受け取ることで、日時の計算が簡単になります。夏時間の移行時にオフセットの変化を考慮する必要がないからです。
もしUTCではなくローカル時間で日時を保存するサードパーティーのデータベースに接続する場合は、このオプションを適切なタイムゾーンに設定する必要があります。同様に、Djangoがデータベースを管理しているが、サードパーティーシステムが同じデータベースに接続し、ローカル時間で日時を取得することを期待している場合は、このオプションを設定する必要があります。
データベースバックエンドがタイムゾーンをサポートしている場合（例えば、PostgreSQL）、データベース接続のタイムゾーンはこの値に設定されます。
\nTIME_ZONE オプションを設定する必要はほとんどありませんが、状況によっては必要になることがあります。特に、PostgreSQLの date_trunc() や generate_series() などの日時関数を使用するクエリに関わる場合、特にサマータイムの切り替えなど、時間ベースのシリーズを生成するときには、一般的な TIME_ZONE 設定と一致させることが推奨されます。
この値はいつでも変更可能であり、データベースは日時を設定されたタイムゾーンに変換します。
\nただし、これには欠点があります。すべての日時をローカルタイムで受け取ると、日時の算術がより複雑になります。DST（サマータイム）の変更期間を考慮に入れる必要があります。
\n素のSQLクエリで TIME_ZONE オプションを設定する代わりに、AT TIME ZONE を使用して明示的にローカルタイムに変換することを検討してください。
DISABLE_SERVER_SIDE_CURSORSLink to this heading#デフォルト値: False
もし QuerySet.iterator() でサーバーサイドのカーソルの使用を無効にしたい場合は、これを True に設定してください。 トランザクションプールとサーバーサイドカーソル には使用例が記載されています。
これは PostgreSQL 固有の設定です。
\nUSERLink to this heading#デフォルト値: '' (空文字列)
データベースに接続する際に使用するユーザー名。SQLiteでは使用されません。
\nTESTLink to this heading#デフォルト値: {} (空の辞書)
テスト用データベースの設定辞書。テスト用データベースの作成と使用に関する詳細については、 test データベース を参照してください。
\n以下はテスト用データベースの設定例です:
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "USER": "mydatabaseuser",\n "NAME": "mydatabase",\n "TEST": {\n "NAME": "mytestdatabase",\n },\n },\n}\nTEST 辞書で利用可能なキーは以下のとおりです:
CHARSETLink to this heading#デフォルト値: None
テストデータベースを作成する際に使用される文字セットエンコーディングです。この文字列の値はデータベースに直接渡されるため、その形式はバックエンドに依存します。
\nPostgreSQL (postgresql) および MySQL (mysql) バックエンドでサポートされています。
COLLATIONLink to this heading#デフォルト値: None
テストデータベースを作成する際に使用する照合順序 (collation)。この値はバックエンドに直接渡されるため、その形式はバックエンドに依存します。
\nmysql バックエンドでのみサポートされています (MySQL manual を参照してください)。
DEPENDENCIESLink to this heading#デフォルト値: ['default'] で、 default 以外のすべてのデータベースには依存関係は設定されていません。
データベースの作成順序の依存関係です。詳細については、 テストデータベースの作成順序を制御する ドキュメントを参照してください。
\nMIGRATELink to this heading#デフォルト値: True
False に設定されている場合、テストデータベースを作成するときにマイグレーションは実行されません。これは MIGRATION_MODULES に None を値として設定するのと似ていますが、すべてのアプリに適用されます。
MIRRORLink to this heading#デフォルト値: None
このデータベースがテスト中にミラーリングするべきデータベースのエイリアスです。トランザクションに依存しているため、 TestCase の代わりに TransactionTestCase 内で使用する必要があります。
この設定は、複数のデータベースのプライマリ/レプリカ (一部のデータベースではマスター/スレーブと呼ばれる) 構成のテストを可能にするために存在します。詳細については、 プライマリ/レプリカ構成のテスト のドキュメントを参照してください。
\nNAMELink to this heading#デフォルト値: None
テストスイートを実行する際に使用するデータベースの名前。
\nデフォルト値 (None) をSQLiteデータベースエンジンで使用すると、テストはメモリ内のデータベースを使用します。そのほかのデータベースエンジンでは、テストデータベースは 'test_' + DATABASE_NAME という名前が使われます。
テストデータベース を参照。
\nTEMPLATELink to this heading#これは PostgreSQL 固有の設定です。
\nテストデータベースを作成するための template の名前 (例: 'template0')。
CREATE_DBLink to this heading#デフォルト値: True
これは Oracle 固有の設定です。
\nFalse に設定されている場合、テストテーブルスペースはテストの開始時に自動的に作成されることも終了時に削除されることもありません。
CREATE_USERLink to this heading#デフォルト値: True
これは Oracle 固有の設定です。
\nFalse に設定されている場合、テストの開始時にテストユーザーは自動的に作成されず、終了時に削除されません。
USERLink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\nテストを実行する際に、Oracle データベースに接続するために使用するユーザー名です。指定しない場合、Django は 'test_' + USER を使用します。
PASSWORDLink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\nテスト実行時に Oracle データベースに接続するために使用するパスワードです。指定しない場合、Django はランダムなパスワードを生成します。
\nORACLE_MANAGED_FILESLink to this heading#デフォルト値: False
これは Oracle 固有の設定です。
\nTrue に設定された場合、Oracle Managed Files (OMF) テーブル空間が使用されます。 DATAFILE と DATAFILE_TMP は無視されます。
TBLSPACELink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\nテスト実行時に使用されるテーブル空間の名前。省略した場合、Django は 'test_' + USER を使用します。
TBLSPACE_TMPLink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\nテスト実行時に使用される一時テーブルスペースの名前。指定しない場合、Djangoは 'test_' + USER + '_temp' を使用します。
DATAFILELink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\n使用する TBLSPACE のデータファイル名です。指定されない場合、Django は TBLSPACE + '.dbf' を使用します。
DATAFILE_TMPLink to this heading#デフォルト値: None
これは Oracle 固有の設定です。
\n使用する TBLSPACE_TMP のデータファイルの名前です。指定されていない場合、Django は TBLSPACE_TMP + '.dbf' を使用します。
DATAFILE_MAXSIZELink to this heading#デフォルト値: '500M'
これは Oracle 固有の設定です。
\nDATAFILE が許容される最大サイズ。
\nDATAFILE_TMP_MAXSIZELink to this heading#デフォルト値: '500M'
これは Oracle 固有の設定です。
\nDATAFILE_TMP が拡大することが許可されている最大サイズ。
\nDATAFILE_SIZELink to this heading#デフォルト値: '50M'
これは Oracle 固有の設定です。
\nDATAFILE の初期サイズ。
\nDATAFILE_TMP_SIZELink to this heading#デフォルト値: '50M'
これは Oracle 固有の設定です。
\nDATAFILE_TMP の初期サイズ。
\nDATAFILE_EXTSIZELink to this heading#デフォルト値: '25M'
これは Oracle 固有の設定です。
\nDATAFILE がより多くのスペースを必要としたときに拡張される量。
\nDATAFILE_TMP_EXTSIZELink to this heading#デフォルト値: '25M'
これは Oracle 固有の設定です。
\n空き領域が不足するときに DATAFILE_TMP が拡張される量。
\nDATA_UPLOAD_MAX_MEMORY_SIZELink to this heading#デフォルト値: 2621440 (例: 2.5 MB)。
The maximum size in bytes that a request body may be before a\nSuspiciousOperation (RequestDataTooBig) is\nraised. The check is done when accessing request.body or request.POST\nand is calculated against the total request size excluding any file upload\ndata (request.FILES). You can set this to None to disable the check.\nApplications that are expected to receive unusually large form posts should\ntune this setting.
Under ASGI, the entire request may be spooled to disk before this limit is\nenforced. Therefore, it is strongly recommended to place additional protections\nin front of Django which limit the entire request payload.
\nThe amount of request data is correlated to the amount of memory or storage\nneeded to process the request and populate the GET and POST dictionaries.\nLarge requests could be used as a denial-of-service attack vector if left\nunchecked. Since web servers don't typically perform deep request inspection,\nit's not possible to perform a similar check at that level.
\n\nDATA_UPLOAD_MAX_NUMBER_FIELDSLink to this heading#デフォルト値: 1000
GET または POST 経由で受け取り可能なパラメータの最大数を超えると、 SuspiciousOperation (TooManyFields) が発生します。このチェックを無効にするには、これを None に設定してください。通常よりも多くのフォームフィールドを受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。
リクエストパラメータの数は、リクエストを処理して GET と POST の辞書を満たすために必要な時間と相関しています。大きなリクエストは、チェックされないままにしておくと、サービス拒否攻撃のベクトルとして使用される可能性があります。Webサーバは通常、深いリクエスト検査を行わないため、そのレベルで同様のチェックを行うことはできません。
\nDATA_UPLOAD_MAX_NUMBER_FILESLink to this heading#デフォルト値: 100
POSTで multipart/form-data エンコードされたリクエスト経由で受信できるファイルの最大数です。この数を超えると SuspiciousOperation (TooManyFiles) が発生します。このチェックを無効にするには、これを None に設定できます。通常よりも多くのファイルフィールドを受信することが予想されるアプリケーションは、この設定を調整する必要があります。
受け入れられるファイルの数は、リクエストを処理するために必要な時間とメモリに関連しています。大きなリクエストは、チェックなしに放置されると、サービス拒否攻撃のベクトルとして使用される可能性があります。Web サーバーは通常、リクエストの深い検査を行わないため、そのレベルで同様のチェックを行うことはできません。
\nDATABASE_ROUTERSLink to this heading#デフォルト値: [] (空のリスト)
データベースクエリを実行する際に使用されるデータベースを決定するために使用されるルーターのリスト。
\n複数データベース構成での自動データベースルーティング に関するドキュメントを参照してください。
\nDATE_FORMATLink to this heading#デフォルト値: 'N j, Y' (例: Feb. 4, 2003)
システムのどの部分でも日付フィールドを表示する際に使用するデフォルトのフォーマット。ただし、ロケールによって指定されたフォーマットが優先され、代わりに適用されます。 使用可能な日付フォーマット文字列 を参照してください。
DATE_INPUT_FORMATSLink to this heading#デフォルト値:
\n[\n "%Y-%m-%d", # '2006-10-25'\n "%m/%d/%Y", # '10/25/2006'\n "%m/%d/%y", # '10/25/06'\n "%b %d %Y", # 'Oct 25 2006'\n "%b %d, %Y", # 'Oct 25, 2006'\n "%d %b %Y", # '25 Oct 2006'\n "%d %b, %Y", # '25 Oct, 2006'\n "%B %d %Y", # 'October 25 2006'\n "%B %d, %Y", # 'October 25, 2006'\n "%d %B %Y", # '25 October 2006'\n "%d %B, %Y", # '25 October, 2006'\n]\n日付フィールドにデータを入力する際に受け入れられる形式のリストです。形式は順番に試され、最初の有効なものが使用されます。これらの形式文字列は、 date テンプレートフィルタからの形式文字列ではなく、Python の datetime モジュールの構文 を使用していることに注意してください。
ロケールが指定するフォーマットが優先され、代わりに適用されます。
\n\nDATETIME_FORMATLink to this heading#デフォルト値: 'N j, Y, P' (例: Feb. 4, 2003, 4 p.m.)
システムのどの部分で日時フィールドを表示する際に使用するデフォルトのフォーマット。ロケールで指定されたフォーマットの方が優先され、代わりに適用されることに注意してください。許可される日付フォーマット文字列については、 使用可能な日付フォーマット文字列 を参照してください。
DATETIME_INPUT_FORMATSLink to this heading#デフォルト値:
\n[\n "%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59'\n "%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200'\n "%Y-%m-%d %H:%M", # '2006-10-25 14:30'\n "%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59'\n "%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200'\n "%m/%d/%Y %H:%M", # '10/25/2006 14:30'\n "%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59'\n "%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200'\n "%m/%d/%y %H:%M", # '10/25/06 14:30'\n]\n日時フィールドにデータを入力する際に受け入れられるフォーマットのリスト。フォーマットは順番に試され、最初の有効なものが使用されます。これらのフォーマット文字列は、date テンプレートフィルタからのフォーマット文字列ではなく、Python の datetime モジュールの構文 を使用することに注意してください。日付のみのフォーマットは含まれていません。というのも、datetime フィールドは最終手段として自動的に DATE_INPUT_FORMATS を試みるからです。
ロケールが指定するフォーマットが優先され、代わりに適用されます。
\n関連項目: DATE_INPUT_FORMATS および TIME_INPUT_FORMATS を参照。
DEBUGLink to this heading#デフォルト値: False
デバッグモードをオン/オフにする真偽値です。
\nDEBUG をオンにした状態でサイトを本番環境にデプロイしないでください。
デバッグモードの主な特徴の一つは、詳細なエラーページの表示です。あなたのアプリが DEBUG が True のときに例外を発生させた場合、Djangoは詳細なトレースバックを表示します。これには、settings.py から現在定義されているすべてのDjango設定など、環境に関する多くのメタデータが含まれています。
セキュリティ対策として、Djangoでは SECRET_KEY のような機密性の高い設定を 含めない ことにしています。具体的には、以下のいずれかを含む名前の設定は除外されます:
'API'
'KEY'
'PASS'
'SECRET'
'SIGNATURE'
'TOKEN'
これらは 部分一致 であることに注意してください。 'PASS' は PASSWORD にも一致し、 'TOKEN' は TOKENIZED にも一致します。
それでも、デバッグ出力のセクションには、公開に適さないものが常に存在することに注意してください。ファイルパス、設定オプションなどは、攻撃者にサーバーについての追加情報を提供してしまいます。
\nまた、DEBUG をオンにして実行している場合、Djangoは実行するすべてのSQLクエリを記憶します。デバッグ時に便利ですが、本番サーバーでは急速にメモリを消費します。
最後に、DEBUG が False の場合は、ALLOWED_HOSTS も適切に設定する必要があります。これを怠ると、すべてのリクエストが "Bad Request (400)" として返されます。
DEBUG_PROPAGATE_EXCEPTIONSLink to this heading#デフォルト値: False
True に設定されている場合、Djangoのビュー関数の例外処理 (handler500 、または DEBUG が True の場合はデバッグビュー) と500レスポンスのログ記録 (django.request) がスキップされ、例外は上に伝播します。
これは、一部のテスト設定で役立つ場合があります。Django の代わりに Web サーバーが "Internal Server Error" のレスポンスを生成することを望む場合を除いて、ライブサイトで使用するべきではありません。その場合、サーバーがレスポンスでスタックトレースやその他の機密情報を表示しないようにしてください。
\nDECIMAL_SEPARATORLink to this heading#デフォルト値: '.' (ドット)
小数をフォーマットする際に使用されるデフォルトの小数点区切り記号です。
\nロケールが指定する形式が優先され、それが適用されるので注意してください。
\n関連項目: NUMBER_GROUPING, THOUSAND_SEPARATOR, USE_THOUSAND_SEPARATOR
DEFAULT_AUTO_FIELDLink to this heading#Default: 'django.db.models.BigAutoField'
フィールドに primary_key=True の属性がないモデルに使用するデフォルトの主キーのフィールドタイプ。
DEFAULT_CHARSETLink to this heading#デフォルト値: 'utf-8'
手動で MIME タイプが指定されていない場合に、全ての HttpResponse オブジェクトで使用するデフォルトの文字セット。Content-Type ヘッダを構築する際に使用されます。
DEFAULT_EXCEPTION_REPORTERLink to this heading#デフォルト値: 'django.views.debug.ExceptionReporter'
まだ HttpRequest インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポータークラス。 カスタムエラーレポート を参照してください。
DEFAULT_EXCEPTION_REPORTER_FILTERLink to this heading#デフォルト値: 'django.views.debug.SafeExceptionReporterFilter'
まだ HttpRequest インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポートフィルタクラス。 エラーレポートのフィルタリング を参照してください。
DEFAULT_FROM_EMAILLink to this heading#デフォルト値: 'webmaster@localhost'
サイト管理者からの自動対応用のデフォルトのメールアドレスです。このアドレスは送信メールの From: ヘッダに使用され、選択したメール送信プロトコルで有効なあらゆる形式を取ることができます。
これは ADMINS と MANAGERS へ送信されるエラーメッセージには影響しません。それについては SERVER_EMAIL を参照してください。
To build an address with a display name from variable content, see\nFormatting email addresses.
\nDEFAULT_INDEX_TABLESPACELink to this heading#デフォルト値: '' (空文字列)
バックエンドがサポートしている場合 (テーブル空間（tablespace） を参照)、指定されていないフィールドのインデックスに使用するデフォルトのテーブル空間です。
\nDEFAULT_TABLESPACELink to this heading#デフォルト値: '' (空文字列)
バックエンドがサポートしている場合、指定していないモデル用に使用するデフォルトのテーブル空間 (テーブル空間（tablespace） を参照)。
\nDISALLOWED_USER_AGENTSLink to this heading#デフォルト値: [] (空のリスト)
どのページも訪れることを許可されていないユーザーエージェント文字列を表すコンパイル済み正規表現オブジェクトのリスト。これはボット/クローラー用です。 CommonMiddleware がインストールされている場合にのみ使用されます（詳細は、 ミドルウェア (Middleware) を参照）。
EMAIL_BACKENDLink to this heading#Default: 'django.core.mail.backends.smtp.EmailBackend'
使用するメール送信のバックエンド。利用可能なバックエンドのリストについては、 メールのバックエンド を参照してください。
\n\nEMAIL_FILE_PATHLink to this heading#デフォルト値: 定義されていません
\nファイルメールバックエンド が出力ファイルを保存するために使用するディレクトリ。
\n\nEMAIL_HOSTLink to this heading#デフォルト値: 'localhost'
E メール送信に使われるホストです。
\nEMAIL_PORT も参照してください。
EMAIL_HOST_PASSWORDLink to this heading#デフォルト値: '' (空文字列)
EMAIL_HOST 内で定義された SMTP サーバで使われるパスワードです。この設定は、STMP サーバへの認証の際に EMAIL_HOST_USER と組み合わせて用いられます。どちらかの設定が空の場合、Django は認証を試みません。
EMAIL_HOST_USER も参照してください。
EMAIL_HOST_USERLink to this heading#デフォルト値: '' (空文字列)
EMAIL_HOST 内で定義された SMTP サーバで使われるユーザ名です。空の場合、Django は認証を試みません。
EMAIL_HOST_PASSWORD も参照してください。
EMAIL_PORTLink to this heading#デフォルト値: 25
EMAIL_HOST 内で定義された SMTP サーバで使われるポート番号です。
EMAIL_SUBJECT_PREFIXLink to this heading#デフォルト値: '[Django] '
django.core.mail.mail_admins や django.core.mail.mail_managers で送信される E メールメッセージ用の表題行のプレフィックスです。最後の文字はスペースにするのが良いでしょう。
EMAIL_USE_LOCALTIMELink to this heading#デフォルト値: False
電子メールメッセージのSMTPの "Date" ヘッダーをローカルタイムゾーンで送信する (True) かUTCで送信する (False) か。
EMAIL_USE_TLSLink to this heading#デフォルト値: False
SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。明示的な TLS 接続に使われ、通常はポート 587 で行われます。接続がハングしてしまう場合は、暗黙的な TLS を示す EMAIL_USE_SSL を確認してみてください。
EMAIL_USE_SSLLink to this heading#デフォルト値: False
SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。ほとんどの E メールのドキュメントでは、この TLS 接続のタイプは SSL として参照されます。通常はポート 465 が使われます。接続がハングしてしまう場合は、暗黙的な TLS を示す EMAIL_USE_TLS を確認してみてください。
EMAIL_USE_TLS/EMAIL_USE_SSL は相互に排他的であることに注意してください。したがって、どちらか一方だけを True にセットしてください。
EMAIL_SSL_CERTFILELink to this heading#デフォルト値: None
EMAIL_USE_SSL または EMAIL_USE_TLS が True で、SMTP サーバーへの安全な接続にクライアント認証が必要な場合、この設定を使用して PEM 形式の証明書チェーンファイルへのパスを指定します。これは EMAIL_SSL_KEYFILE と併せて使用する必要があります。
EMAIL_SSL_CERTFILE は、自己署名のサーバー証明書や私設認証局（CA）の証明書と併用すべきではありません。これらの場合、サーバー証明書（または私設 CA のルート証明書）をシステムの CA バンドルにインストールする必要があります。これは、プラットフォーム固有のルート CA 証明書のインストール手順に従うか、OpenSSL の SSL_CERT_FILE または SSL_CERT_DIR 環境変数を使用してカスタム証明書バンドルを指定することで行えます（システムのバンドルを変更できない、または変更したくない場合）。
For more complex scenarios, the SMTP EmailBackend can be subclassed to add root certificates to its\nssl_context using\nssl.SSLContext.load_verify_locations().
EMAIL_SSL_KEYFILELink to this heading#デフォルト値: None
EMAIL_USE_SSL または EMAIL_USE_TLS が True の場合、SSL 接続のクライアント認証のための PEM 形式の秘密鍵ファイルへのパスを、EMAIL_SSL_CERTFILE と併せて任意で指定できます。
EMAIL_SSL_CERTFILE と EMAIL_SSL_KEYFILE を設定しても、いかなる証明書のチェックも行われません。これらは基礎となる SSL 接続に渡されます。証明書チェーンファイルと秘密鍵ファイルの取り扱いの詳細については、Python の ssl.SSLContext.wrap_socket() 関数のドキュメントを参照してください。
EMAIL_TIMEOUTLink to this heading#デフォルト値: None
接続試行のような操作をブロックするためのタイムアウトを秒で指定します。
\n\nFILE_UPLOAD_HANDLERSLink to this heading#デフォルト値:
\n[\n "django.core.files.uploadhandler.MemoryFileUploadHandler",\n "django.core.files.uploadhandler.TemporaryFileUploadHandler",\n]\nアップロードに使用するハンドラのリストです。この設定を変更すると、Djangoのアップロードプロセスを完全にカスタマイズできます。代替も可能です。
\nSee アップロードハンドラ for details.
\nFILE_UPLOAD_MAX_MEMORY_SIZELink to this heading#デフォルト値: 2621440 (例: 2.5 MB)。
The maximum size (in bytes) that an upload will be before it gets streamed to\nthe file system. See アップロードハンドラ for details.
\n\nFILE_UPLOAD_DIRECTORY_PERMISSIONSLink to this heading#デフォルト値: None
ファイルのアップロードの過程で作成されるディレクトリに適用する数値モード。
\nこの設定は、 collectstatic 管理コマンドを使用する際の、収集された静的ディレクトリのデフォルト権限も決定します。それを上書きする方法の詳細については、 collectstatic を参照してください。
この値には FILE_UPLOAD_PERMISSIONS 設定の機能と同様の注意点があります。
FILE_UPLOAD_PERMISSIONSLink to this heading#デフォルト値: 0o644
新しくアップロードされたファイルに設定する数値モード（例えば 0o644 ）です。これらのモードが何を意味するのかについての詳細は、 os.chmod() のドキュメントを参照してください。
もし None なら、OS 依存の動作が得られます。ほとんどのプラットフォームでは、一時ファイルは 0o600 のモードを持ち、メモリから保存されるファイルはシステムの標準の umask を使用して保存されます。
セキュリティ上の理由から、これらの権限は FILE_UPLOAD_TEMP_DIR に保存される一時ファイルには適用されません。
この設定は、collectstatic 管理コマンドを使用して静的ファイルを収集する際のデフォルト権限も決定します。それをオーバーライドする方法については、 collectstatic を参照してください。
FILE_UPLOAD_TEMP_DIRLink to this heading#デフォルト値: None
ファイルをアップロードしている間にデータ (通常は FILE_UPLOAD_MAX_MEMORY_SIZE より大きなファイル) を一時的に保存するディレクトリ。None の場合、Djangoはオペレーティングシステムの標準的な一時ディレクトリを使用します。たとえば、これは *nix スタイルのオペレーティングシステムではデフォルトで /tmp になります。
See アップロードハンドラ for details.
\nFIRST_DAY_OF_WEEKLink to this heading#デフォルト値: 0 (日曜日)
週の最初の日を表す数字。カレンダーを表示する際に特に役立ちます。この値は、フォーマットの国際化が行われていない場合や、現在のロケールに対応するフォーマットが見つからない場合にのみ使用されます。
\n値は0から6までの整数でなければなりません。0は日曜日、1は月曜日、以降も同様です。
\nFIXTURE_DIRSLink to this heading#デフォルト値: [] (空のリスト)
フィクスチャ ファイルを検索するために、各アプリケーションの fixtures ディレクトリに加えて検索されるディレクトリのリスト。検索順。
これらのパスは、Windows でも Unix スタイルのスラッシュ (/) を使う必要があります。
\nフィクスチャでデータを投入する と フィクスチャのロード を参照してください。
\nFORCE_SCRIPT_NAMELink to this heading#デフォルト値: None
If not None, this will be used as the value of the SCRIPT_NAME\nenvironment variable in any HTTP request. This setting can be used to override\nthe server-provided value of SCRIPT_NAME, which may be a rewritten version\nof the preferred value or not supplied at all. It is also used by\ndjango.setup() to set the URL resolver script prefix outside of the\nrequest/response cycle (e.g. in management commands and standalone scripts) to\ngenerate correct URLs when FORCE_SCRIPT_NAME is provided.
FORM_RENDERERLink to this heading#デフォルト値: 'django.forms.renderers.DjangoTemplates'
フォームやフォームウィジェットをレンダリングするクラスです。低レベルレンダリングAPI を実装する必要があります。含まれるフォームレンダラは次の通りです。
\n\nFORMAT_MODULE_PATHLink to this heading#デフォルト値: None
プロジェクトのロケールに対するカスタムフォーマット定義を含むPythonパッケージへの完全なPythonパス。None でない場合、Djangoは現在のロケールとして名付けられたディレクトリの下にある formats.py ファイルをチェックし、このファイルで定義されているフォーマットを使用します。
フォーマットの定義があるディレクトリ名は、locale name 表記を使用した名前であることが期待されます。たとえば、de、pt_BR、en_US などです。
たとえば、FORMAT_MODULE_PATH が mysite.formats に設定され、現在の言語が en (英語) である場合、Djangoは次のようなディレクトリ構造を期待します:
mysite/\n formats/\n __init__.py\n en/\n __init__.py\n formats.py\nこの設定には、Python のパスのリストを設定することもできます。たとえば:
\nFORMAT_MODULE_PATH = [\n "mysite.formats",\n "some_app.formats",\n]\nDjango が特定のフォーマットを検索する際、与えられた Python パス全体を通過し、実際にそのフォーマットを定義しているモジュールが見つかるまで探します。つまり、リストの上位にあるパッケージで定義されたフォーマットが、下位にある同じフォーマットより優先されます。
\n利用可能なフォーマットは以下の通りです:
\n\nIGNORABLE_404_URLSLink to this heading#デフォルト値: [] (空のリスト)
List of compiled regular expression objects describing URLs that should be\nignored when reporting HTTP 404 errors via email (see\nエラーレポートの管理). Regular expressions are matched against\nrequest's full paths, as returned by\nget_full_path() (including any query strings).\nUse this if your site does not provide a commonly requested file such as\nfavicon.ico or robots.txt.
これは、 BrokenLinkEmailsMiddleware が有効になっている場合にのみ使用されます（詳細は、 ミドルウェア (Middleware) を参照）。
INSTALLED_APPSLink to this heading#デフォルト値: [] (空のリスト)
このDjangoインストールで有効になっているすべてのアプリケーションを示す文字列のリスト。各文字列は、Pythonのドット区切りパスである必要があります。
\nアプリケーションの設定クラス（推奨）、または
アプリケーションを含むパッケージ。
いくつかのアプリケーションが同じリソース（テンプレート、静的ファイル、管理コマンド、翻訳）の異なるバージョンを提供する場合、 INSTALLED_APPS で最初にリストされたアプリケーションが優先されます。
INTERNAL_IPSLink to this heading#デフォルト値: [] (空のリスト)
文字列としての IP アドレスのリストで、以下の条件を満たします:
\ndebug() コンテキストプロセッサを許可して、テンプレートコンテキストにいくつかの変数を追加します。
スタッフユーザーとしてログインしていなくても、 admindocsブックマークレット を使用できます。
AdminEmailHandler の電子メールで（"EXTERNAL" に対して）"internal" とマークされます。
LANGUAGE_CODELink to this heading#デフォルト値: 'en-us'
このインストールに対する言語コードを表す文字列です。標準の 言語 ID フォーマット 内にある文字列を指定します。例えば、U.S. の英語は "en-us" です。list of language identifiers と 国際化とローカライズ も参照してください。
これは次の3つの目的を果たします。
\nロケールミドルウェアが使用されていない場合、全ユーザにどの翻訳を提供するかを決めます。
ロケールミドルウェアがアクティブの場合、ユーザの好む言語が不明な場合やウェブサイトでサポートされていない場合に備えて、フォールバックの言語として利用されます。また、与えられた文字列に対して、ユーザの好む言語に対応する翻訳が存在しない場合にも、この設定が利用されます。
ローカライズが unlocalize フィルターや {% localize off %} タグで明示的に無効にされた場合、代わりにフォールバックのローカライズ形式が適用されます。詳細については、テンプレートでのローカライズの制御 を参照してください。
詳しくは Django はどうやって言語の優先順位を検出するのか？ を参照してください。
\nLANGUAGESLink to this heading#デフォルト値: 利用可能な全言語のリストです。このリストは常に拡大しており、ここにコピーを含めると速やかに時代遅れになってしまいます。現在の翻訳された言語のリストは、 django/conf/global_settings.py で確認できます。
\nリストは、(言語コード, 言語名) の形式の 2値タプルのリストです。例えば、('ja', 'Japanese') です。これは言語選択で利用可能な言語を指定します。詳細は 国際化とローカライズ を参照してください。
一般的には、デフォルト値で十分です。Django が提供する言語の部分集合に選択肢を限定したいときにのみ、この設定を自分でセットしてください。
\nカスタム LANGUAGES 設定を定義した場合、 gettext_lazy() 関数を使って言語名を翻訳文字列としてマークすることができます。
以下はサンプルの設定ファイルです:
\nfrom django.utils.translation import gettext_lazy as _\n\nLANGUAGES = [\n ("de", _("German")),\n ("en", _("English")),\n]\nLANGUAGES_BIDILink to this heading#デフォルト値: 右から左へ向かって書く言語のコード一覧です。これらの言語の現在の一覧は、 django/conf/global_settings.py を見ることで確認できます。
\nリストには、右から左へ書かれる言語の 言語コード が含まれています。
\n基本的にはデフォルト値で十分です。Django が提供する言語のサブセットに言語選択を制限したい場合にのみ、この設定を設定してください。カスタムな LANGUAGES 設定を定義すると、双方向言語のリストに、特定サイトで有効になっていない言語コードが含まれる可能性があります。
LOCALE_PATHSLink to this heading#デフォルト値: [] (空のリスト)
Django が翻訳ファイルを探すディレクトリのリストです。Djangoはどうやって翻訳を見つけるのか？ を参照してください。
\n実装例:
\nLOCALE_PATHS = [\n "/home/www/project/common_files/locale",\n "/var/local/translations/locale",\n]\nDjango は、実際の翻訳ファイルを含む <locale_code>/LC_MESSAGES ディレクトリに対して、これらのパス内をそれぞれ見ていきます。
LOGGINGLink to this heading#デフォルト値: ロギング設定のディレクトリ。
\n設定情報を含むデータ構造です。このデータ構造が空でない場合、その内容は LOGGING_CONFIG で説明されている設定メソッドへの引数として渡されます。
デフォルトのロギング設定では、 DEBUG が False の場合、HTTP 500 サーバーエラーをメールログハンドラーに送信します。詳細は、 ロギングを設定する を参照してください。
デフォルトのログ設定は、 django/utils/log.py で確認できます。
\nLOGGING_CONFIGLink to this heading#デフォルト値: 'logging.config.dictConfig'
Django プロジェクトでロギングを設定するために使用される呼び出し可能オブジェクトへのパス。デフォルトでは Python の dictConfig 設定形式のインスタンスを指しています。
\nLOGGING_CONFIG を None に設定すると、ロギング設定プロセスはスキップされます。
MAILERSLink to this heading#デフォルト値: 定義されていません
\nA dictionary containing the settings for all email backends to be used with\nDjango. It is a nested dictionary that maps backend aliases to dictionaries\ncontaining each mailer's backend import path and configuration options.
\n実装例:
\nMAILERS = {\n "default": {\n "BACKEND": "django.core.mail.backends.smtp.EmailBackend",\n "OPTIONS": {\n "host": "smtp.example.net",\n },\n },\n "newsletters": {\n "BACKEND": "django.core.mail.backends.smtp.EmailBackend",\n "OPTIONS": {\n "host": "smtp.bulk-email-service.example.com",\n "username": os.environ["BULK_EMAIL_SERVICE_ACCOUNT_ID"],\n "password": os.environ["BULK_EMAIL_SERVICE_API_KEY"],\n "use_tls": True,\n },\n },\n}\nIf you plan to send email through Django, configuring at least a "default"\nmailer is recommended. Any number of additional mailers may also be specified.\nDepending on which backend is used, other options may be required.
Setting MAILERS to an empty dictionary ({}) disables email sending and\nany attempt to send mail will raise MailerDoesNotExist.
See Configuring email for more information.
\n\nBACKENDLink to this heading#Default: "django.core.mail.backends.smtp.EmailBackend"
The Python import path to the email backend class. If "BACKEND" is omitted,\nDjango's SMTP バックエンド is used.
See メールのバックエンド for a list of Django's built-in backends and\npointers to community-maintained options.
\nOPTIONSLink to this heading#Default: {}
Configuration parameters to pass to the email backend. The available and\nrequired options vary depending on the backend.
\nMANAGERSLink to this heading#デフォルト値: [] (空のリスト)
ADMINS と同じ形式のリストで、 BrokenLinkEmailsMiddleware が有効な場合に、誰がリンク切れ通知を受け取るべきかを指定します。
MEDIA_ROOTLink to this heading#デフォルト値: '' (空文字列)
ユーザーがアップロードしたファイル を保存するディレクトリへの絶対ファイルシステムパス。
\n例: "/var/www/example.com/media/"
関連項目: MEDIA_URL
MEDIA_URLLink to this heading#デフォルト値: '' (空文字列)
MEDIA_ROOT から提供されるメディアを扱う URL は、保存されたファイルの管理 に使用されます。空でない値に設定されている場合は、スラッシュで終わる必要があります。開発環境と本番環境の両方で、これらのファイルが配信されるように 設定する必要があります 。
テンプレートで {{ MEDIA_URL }} を使用したい場合は、 TEMPLATES の 'context_processors' オプションに 'django.template.context_processors.media' を追加してください。
例: "https://media.example.com/"
MIDDLEWARELink to this heading#デフォルト値: None
使用するミドルウェアのリストです。 ミドルウェア (Middleware) を参照してください。
\nMIGRATION_MODULESLink to this heading#デフォルト値: {} (空の辞書)
アプリごとにマイグレーションモジュールを検索できるパッケージを指定する辞書です。この設定のデフォルト値は空の辞書ですが、マイグレーションモジュールのデフォルトパッケージ名は migrations です。
実装例:
\n{"blog": "blog.db_migrations"}\nこの場合、blog アプリに関連するマイグレーションは blog.db_migrations パッケージに含まれます。
app_label 引数を提供した場合、makemigrations はパッケージがまだ存在しない場合、自動的にパッケージを作成します。
アプリに対して None を値として指定すると、Djangoはそのアプリをマイグレーションを持たないアプリとみなします。これは、例えば、テストの設定ファイルにおいてマイグレーションをスキップしながらテストを行うために使用できます (アプリのモデルのためにテーブルは依然として作成されます)。テスト中にすべてのアプリのマイグレーションを無効にするには、代わりに MIGRATE を False に設定できます。プロジェクトの一般的な設定で MIGRATION_MODULES を使用している場合、アプリのためにテーブルを作成したい場合は migrate --run-syncdb オプションを使用してください。
MONTH_DAY_FORMATLink to this heading#デフォルト値: 'F j'
admin change-list のページの日付をフォーマットする時のデフォルト値です。システムの他の場所で月と日だけが表示される場合に使用される可能性があります。
\nたとえば、Django の admin change-list のページを日付でフィルタする時、与えられた日付のヘッダには月と日が表示されます。
\n対応するロケールによる書式が優先され、適用されることに留意してください。
\n使用可能な日付フォーマット文字列 を参照してください。また、DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT も参照してください。
NUMBER_GROUPINGLink to this heading#デフォルト値: 0
数の整数部分をまとめるときの桁数です。
\nよくある使われ方は、1000倍の区切り文字を表示するときです。0 に設定すると、数に対してグルーピングを行いません。0 より大きい値を指定すると、 THOUSAND_SEPARATOR が区切り位置を求めるのに使います。
一部の地域では、数字の桁区切りが一様でないことがあります。たとえば、en_IN では 10,00,00,000 のようになります。この場合、適用するべき桁グループの数を示すシーケンスを提供できます。最初の数値は小数点区切り記号の前のグループのサイズを定義し、それに続く各数値は前のグループのサイズを定義します。シーケンスが -1 で終了すると、さらなるグループ分けは行われません。シーケンスが 0 で終了すると、最後のグループのサイズが残りの数値に適用されます。
en_IN のための例のタプル:
NUMBER_GROUPING = (3, 2, 0)\nロケールが指定する形式が優先され、それが適用されるので注意してください。
\nDECIMAL_SEPARATOR, THOUSAND_SEPARATOR, USE_THOUSAND_SEPARATOR も参照してください。
PREPEND_WWWLink to this heading#デフォルト値: False
"www." サブドメインが URL に含まれていない時、自動的に頭に追加するかどうかを指定します。この設定が有効になるのは、 CommonMiddleware がインストールされている時のみです (参照: ミドルウェア (Middleware))。APPEND_SLASH も参照してください。
ROOT_URLCONFLink to this heading#デフォルト値: 定義されていません
\nあなたのルートURLconfへの完全なPythonインポートパスを表す文字列です。例えば "mydjangoapps.urls" のようになります。受け取る HttpRequest オブジェクトの urlconf 属性を設定することで、リクエストごとにオーバーライドできます。詳細については Django のリクエスト処理 を参照してください。
SECRET_KEYLink to this heading#デフォルト値: '' (空文字列)
Django のインストールごとに設定される個別の秘密鍵です。暗号署名 に使われる鍵であり、ユニークかつ予測できない値でなければなりません。
\ndjango-admin startproject コマンドを実行すると、新しいプロジェクトを作成するたびに、ランダムに生成された SECRET_KEY を自動的に設定してくれます。
キーを使用する際、テキストまたはバイトであるとは仮定すべきではありません。使用する際は必ず、それを目的の型に変換するために、 force_str() または force_bytes() を通して行う必要があります。
SECRET_KEY が設定されていない場合、Django は起動しません。
秘密鍵は次のような場合に使われます。
\nAll sessions if you are using\nany other session backend than django.contrib.sessions.backends.cache,\nor are using the default\nget_session_auth_hash().
CookieStorage または FallbackStorage を使用している場合、すべての messages 。
すべての PasswordResetView トークン。
異なるキーが指定されていない限り、すべての 暗号署名 の使用。
SECRET_KEY で設定されていない、または SECRET_KEY_FALLBACKS に含まれていない秘密鍵は、上記のすべてが無効になります。秘密鍵をローテーションさせるときは、古い鍵を一時的に SECRET_KEY_FALLBACKS に移動するべきです。秘密鍵は、ユーザーのパスワードには使用されず、鍵のローテーションがそれらに影響を与えることはありません。
SECRET_KEY_FALLBACKSLink to this heading#デフォルト値: []
特定のDjangoインストールに関連するフォールバックの秘密鍵のリストです。これらは、 SECRET_KEY のローテーションを可能にするために使用されます。
秘密鍵をローテーションするために、新しい SECRET_KEY を設定し、以前の値を SECRET_KEY_FALLBACKS の最初に移動してください。その後、それらを使用するセッション、パスワードリセットトークンなどを期限切れにする準備ができたら、SECRET_KEY_FALLBACKS の最後から古い値を削除してください。
秘密キーの値の使用時は、それらがテキストまたはバイトであると仮定すべきではありません。使用する際には、希望のタイプに変換するために force_str() または force_bytes() を通じて行うべきです。
SECURE_CONTENT_TYPE_NOSNIFFLink to this heading#デフォルト値: True
True であれば、 SecurityMiddleware は、既にそれを持っていないすべてのレスポンスに X-Content-Type-Options: nosniff ヘッダーを設定します。
SECURE_CROSS_ORIGIN_OPENER_POLICYLink to this heading#デフォルト値: 'same-origin'
None に設定されていない限り、 SecurityMiddleware はそれが既に設定されていないすべてのレスポンスに、提供された値を使用して 同一生成元ポリシー (Cross-Origin Opener Policy) ヘッダを設定します。
SECURE_CSPLink to this heading#Default: {}
This setting defines the directives used by the\nContentSecurityPolicyMiddleware, which\ngenerates and adds a Content-Security-Policy (CSP) header\nto all responses that do not already include one.
The Content-Security-Policy header instructs browsers to restrict which\nresources a page is allowed to load. A properly configured CSP can block\ncontent that violates defined rules, helping prevent cross-site scripting (XSS)\nand other content injection attacks by explicitly declaring trusted sources for\ncontent such as scripts, styles, images, fonts, and more.
The setting must be a mapping (typically a dictionary) of directive names to\ntheir values. Each key should be a valid CSP directive such as default-src\nor script-src. The corresponding value can be a list, tuple, or set of\nsource expressions or URLs to allow for that directive. If a set is used, it\nwill be automatically sorted to ensure consistent output in the generated\nheaders.
This example illustrates the expected structure, using the constants defined in\nCSP 定数:
\nfrom django.utils.csp import CSP\n\nSECURE_CSP = {\n "default-src": [CSP.SELF],\n "img-src": ["data:", CSP.SELF, "https://images.example.com"],\n "frame-src": [CSP.NONE],\n}\nSECURE_CSP_REPORT_ONLYLink to this heading#Default: {}
This setting is just like SECURE_CSP, but instead of enforcing the\npolicy, it instructs the\nContentSecurityPolicyMiddleware to apply a\nContent-Security-Policy-Report-Only header to responses, which allows\nbrowsers to monitor and report policy violations without blocking content. This\nis useful for testing and refining a policy before enforcement.
Most browsers log CSP violations to the developer console and can optionally\nsend them to a reporting endpoint. To collect these reports, the report-uri\ndirective must be defined (see Policy violation reports for more details).
As noted in the MDN documentation on Content-Security-Policy-Report-Only,\nthe report-uri directive must be specified for reports to be sent;\notherwise, the header has no reporting effect (other than logging to the\nbrowser's developer tools console).
Following the example from the SECURE_CSP setting:
from django.utils.csp import CSP\n\nSECURE_CSP_REPORT_ONLY = {\n "default-src": [CSP.SELF],\n "img-src": ["data:", CSP.SELF, "https://images.example.com"],\n "frame-src": [CSP.NONE],\n "report-uri": "/my-site/csp/reports/",\n}\nSECURE_HSTS_INCLUDE_SUBDOMAINSLink to this heading#デフォルト値: False
True の場合、 SecurityMiddleware は HTTP Strict Transport Security ヘッダーに includeSubDomains ディレクティブを追加します。 SECURE_HSTS_SECONDS が 0 でない値に設定されていない限り、効果はありません。
SECURE_HSTS_PRELOADLink to this heading#デフォルト値: False
True の場合、 SecurityMiddleware は preload 指令を HTTP Strict Transport Security ヘッダーに追加します。これは SECURE_HSTS_SECONDS が非ゼロの値に設定されていない限り、効果がありません。
SECURE_HSTS_SECONDSLink to this heading#デフォルト値: 0
ゼロでない整数値に設定されている場合、 SecurityMiddleware は、まだ設定されていないすべてのレスポンスに対して HTTP Strict Transport Security ヘッダを設定します。
SECURE_PROXY_SSL_HEADERLink to this heading#デフォルト値: None
リクエストが安全であることを示す HTTP ヘッダー/値の組み合わせを表すタプル。これはリクエストオブジェクトの is_secure() メソッドの動作を制御します。
デフォルトでは、is_secure() はリクエストがセキュアかどうかを確認するためにリクエストされたURLが https:// を使用しているかどうかを判定します。このメソッドはDjangoのCSRF保護に重要であり、あなた自身のコードやサードパーティのアプリでも使用されるかもしれません。
もし Django アプリがプロキシの背後にある場合、プロキシが元のリクエストが HTTPS を使用しているかどうかを「隠して」しまうことがあります。プロキシと Django の間に非 HTTPS 接続がある場合、is_secure() は常に False を返します。これはエンドユーザーが HTTPS 経由で行ったリクエストであってもです。対照的に、プロキシと Django の間に HTTPS 接続がある場合、is_secure() は常に True を返します。これは元々 HTTP 経由で行われたリクエストであってもです。
この状況では、プロキシを設定してカスタムHTTPヘッダーを設定し、リクエストがHTTPS経由で来たかどうかをDjangoに伝え、そして SECURE_PROXY_SSL_HEADER を設定してDjangoがどのヘッダーを探すべきかを知らせます。
2つの要素を持つタプルを設定します。検索するヘッダーの名前と必要な値です。例えば:
\nSECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")\nこれは、次のような場合に、プロキシから来る X-Forwarded-Proto ヘッダーを Django が信頼し、リクエストが安全であること（つまり、元々は HTTPS を介して入ってきた）を保証するように指示します:
ヘッダーの値が 'https' であるか、または
その初期値、プロトコルのカンマ区切りリスト (例: 'https,http,http') の最も左の値が 'https' の場合。
この設定は、プロキシを制御している場合、またはこのヘッダーを適切に設定/削除するという他の保証がある場合にのみ設定すべきです。
\nヘッダーは request.META で使われる形式にする必要があります。すべて大文字で、おそらく HTTP_ で始まります。(Django は、ヘッダー名の先頭に 'HTTP_' を自動的に追加してから、ヘッダーを request.META で利用可能にします。)
SECURE_REDIRECT_EXEMPTLink to this heading#デフォルト値: [] (空のリスト)
このリスト内の正規表現にURLパスが一致する場合、リクエストはHTTPSへリダイレクトされません。 SecurityMiddleware はURLパスから先頭のスラッシュを削除するため、パターンにはそれを含めるべきではありません。例: SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …] 。SECURE_SSL_REDIRECT が False の場合、この設定は効果がありません。
SECURE_REFERRER_POLICYLink to this heading#デフォルト値: 'same-origin'
設定されていれば、 SecurityMiddleware は、それがまだ設定されていないすべてのレスポンスに対して、提供された値に従って リファラ・ポリシー ヘッダーを設定します。
SECURE_SSL_HOSTLink to this heading#デフォルト値: None
文字列 (例: secure.example.com) を設定すると、すべてのSSLリダイレクトが元々リクエストされたホスト (例: www.example.com) の代わりにこのホストに向けられます。 SECURE_SSL_REDIRECT が False の場合、この設定は無効です。
SECURE_SSL_REDIRECTLink to this heading#デフォルト値: False
もし True なら、 SecurityMiddleware は、全てのHTTPSではないリクエストをHTTPSに リダイレクト します (SECURE_REDIRECT_EXEMPT でリストされた正規表現に一致するURLを除く)。
SERIALIZATION_MODULESLink to this heading#デフォルト値: 定義されていません
\nシリアライゼーションタイプに対する文字列識別子をキーとし、シリアライザ定義 (文字列として提供される) を含むモジュールのディクショナリです。例えば、YAML シリアライザを定義するには、以下を使用します。
\nSERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}\nSERVER_EMAILLink to this heading#デフォルト値: 'root@localhost'
エラーメッセージが送信されるメールアドレスは、 ADMINS や MANAGERS に送信されるメールの送信元となるアドレスです。このアドレスは、選択したメール送信プロトコルで有効な任意の形式を取ることができます。
To build an address with a display name from variable content, see\nFormatting email addresses.
\n\nSHORT_DATE_FORMATLink to this heading#デフォルト値: 'm/d/Y' (例: 12/31/2003)
テンプレートで日付フィールドを表示するために利用できるフォーマットです。但し、対応するロケールによって指定されたフォーマットが優先され、代わりに適用されます。詳細は、 使用可能な日付フォーマット文字列 を参照してください。
関連項目: DATE_FORMAT, SHORT_DATETIME_FORMAT
SHORT_DATETIME_FORMATLink to this heading#デフォルト値: 'm/d/Y P' (例: 12/31/2003 4 p.m.)
テンプレートで日時フィールドを表示するために使用できる利用可能なフォーマットです。対応するロケールに従ったフォーマットが優先され、代わりに適用されます。詳細は、 利用可能な文字列フォーマット をご覧ください。
関連項目: DATE_FORMAT, SHORT_DATE_FORMAT
SIGNING_BACKENDLink to this heading#デフォルト値: 'django.core.signing.TimestampSigner'
クッキーやその他のデータに署名する際に使用されるバックエンド。
\n関連項目: 暗号署名 ドキュメント
\nSILENCED_SYSTEM_CHECKSLink to this heading#デフォルト値: [] (空のリスト)
システムチェックフレームワークによって生成されたメッセージの識別子リスト (例: ["models.W001"]) で、永久に認識し、無視したいものです。無視されたチェックはコンソールに出力されません。
関連項目: システムチェックフレームワーク ドキュメント
\nSTORAGESLink to this heading#デフォルト値:
\n{\n "default": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n },\n "staticfiles": {\n "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",\n },\n}\nDjangoで使用されるすべてのストレージの設定を含む辞書です。 ストレージエイリアスを個々のストレージのオプションを含む辞書にマッピングした入れ子構造の辞書です。
\nストレージには任意のエイリアスを指定できます。ただし、特別な意味を持つ2つのエイリアスがあります。
\ndefault は ファイルを管理する ためのものです。 'django.core.files.storage.FileSystemStorage' がデフォルトのストレージエンジンです。
staticfiles は 静的ファイルの管理 用です。 'django.contrib.staticfiles.storage.StaticFilesStorage' がデフォルトのストレージエンジンです。
以下は、カスタムファイルストレージ example を定義する settings.py のコードの例です。
STORAGES = {\n # ...\n "example": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n "OPTIONS": {\n "location": "/example",\n "base_url": "/example/",\n },\n },\n}\n**kwargs を使って、 BACKEND の初期化時に OPTIONS が渡されます。
使用可能なストレージバックエンドのインスタンスは、 django.core.files.storage.storages から取得できます。 STORAGES でのバックエンド定義に対応するキーを使用してください。
TASKSLink to this heading#デフォルト値:
\n{\n "default": {\n "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",\n }\n}\nA dictionary containing the settings for all Task backends to be used with\nDjango. It is a nested dictionary whose contents maps backend aliases to a\ndictionary containing the options for each backend.
\nThe TASKS setting must configure a default backend; any number\nof additional backends may also be specified. Depending on which backend is\nused, other options may be required. The following options are available as\nstandard.
BACKENDLink to this heading#デフォルト値: '' (空文字列)
The Tasks backend to use. The built-in backends are:
\n'django.tasks.backends.dummy.DummyBackend'
'django.tasks.backends.immediate.ImmediateBackend'
You can use a backend that doesn't ship with Django by setting\nBACKEND to a fully-qualified path of a backend\nclass (i.e. mypackage.backends.whatever.WhateverBackend).
QUEUESLink to this heading#Default: ["default"]
Specify the queue names supported by the backend. This can be used to ensure\nTasks aren't enqueued to queues which do not exist.
\nTo disable queue name validation, set to an empty list ([]).
OPTIONSLink to this heading#Default: {}
Extra parameters to pass to the Task backend. Available parameters vary\ndepending on the Task backend.
\nTEMPLATESLink to this heading#デフォルト値: [] (空のリスト)
Django で使用されるすべてのテンプレートエンジンの設定を含むリストです。リストの各項目は、個々のエンジンのオプションを含む辞書です。
\n以下の設定では、Django テンプレートエンジンに対し、インストールされた各アプリケーション内の templates サブディレクトリからテンプレートを読み込むよう指示します:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "APP_DIRS": True,\n },\n]\nすべてのバックエンドで利用可能なオプションは以下の通りです:
\nBACKENDLink to this heading#デフォルト値: 定義されていません
\n使用するテンプレートバックエンドです。内蔵のテンプレートバックエンドは以下の通りです:
\n'django.template.backends.django.DjangoTemplates'
'django.template.backends.jinja2.Jinja2'
Django に付属していないテンプレートバックエンドを使用するには、BACKEND を完全修飾パス (例： 'mypackage.whatever.Backend') で設定します。
NAMELink to this heading#デフォルト値: 下記を参照してください
\nこの特定のテンプレートエンジンのエイリアス。エンジンを選択するための識別子です。エイリアスは、構成されたすべてのテンプレートエンジンで一意である必要があります。
\nエンジンクラスを定義するモジュールの名前がデフォルト値です。つまり、指定されていない場合 BACKEND の最後から2番目の要素になります。例えば、バックエンドが 'mypackage.whatever.Backend' であれば、そのデフォルト名は 'whatever' になります。
DIRSLink to this heading#デフォルト値: [] (空のリスト)
エンジンがテンプレートのソースファイルを探すべきディレクトリ、検索順序付き。
\nAPP_DIRSLink to this heading#デフォルト値: False
エンジンがインストールされたアプリケーション内でテンプレートのソースファイルを探すべきかどうか。
\n\nOPTIONSLink to this heading#デフォルト値: {} (空のディクショナリ)
テンプレートバックエンドに渡す追加のパラメーターです。 利用可能なパラメーターは、テンプレートバックエンドによって異なります。 組み込みバックエンドのオプションについては、 DjangoTemplates と Jinja2 を参照してください。
TEST_RUNNERLink to this heading#デフォルト値: 'django.test.runner.DiscoverRunner'
テストスイートを開始するために使用するクラスの名前。 ほかのテストフレームワークを使う を参照してください。
\nTEST_NON_SERIALIZED_APPSLink to this heading#デフォルト値: [] (空のリスト)
TransactionTestCase やトランザクションを使用しないデータベースバックエンドのテスト間でデータベースの状態を復元するために、Djangoはテスト実行が開始されると すべてのアプリの内容をシリアライズ し、それを必要とするテストを実行する前にそのコピーからリロードできるようにします。
これによって、テストランナーの起動時間が遅くなります。この機能が不要なアプリがある場合は、完全な名前をここに追加して、このシリアライズ処理から除外できます (例: 'django.contrib.contenttypes')。
THOUSAND_SEPARATORLink to this heading#デフォルト値: ',' (カンマ)
数字のフォーマット時に使用するデフォルトの千の区切り記号です。この設定は、USE_THOUSAND_SEPARATOR が True であり、NUMBER_GROUPING が 0 より大きい場合にのみ使用されます。
ロケールが指定する形式が優先され、それが適用されるので注意してください。
\n関連項目: NUMBER_GROUPING, DECIMAL_SEPARATOR, USE_THOUSAND_SEPARATOR
TIME_FORMATLink to this heading#デフォルト値: 'P' (例: 4 p.m.)
システムのどの部分でも、時間フィールドを表示する際に使用するデフォルトの書式設定です。ロケールに依存する書式が優先され、代わりに適用されます。 使用可能な日付フォーマット文字列 を参照してください。
関連項目: DATE_FORMAT, DATETIME_FORMAT
TIME_INPUT_FORMATSLink to this heading#デフォルト値:
\n[\n "%H:%M:%S", # '14:30:59'\n "%H:%M:%S.%f", # '14:30:59.000200'\n "%H:%M", # '14:30'\n]\n時間フィールドでデータを入力するときに受け入れられる形式のリストです。形式は順番に試され、最初の有効なものが使用されます。これらの形式文字列は、 date テンプレートフィルタからの形式文字列ではなく、Pythonの datetime モジュールの構文 を使用していることに注意してください。
ロケールが指定するフォーマットが優先され、代わりに適用されます。
\n関連項目: DATE_INPUT_FORMATS および DATETIME_INPUT_FORMATS を参照してください。
TIME_ZONELink to this heading#デフォルト値: 'America/Chicago'
このインストールのタイムゾーンを表す文字列です。タイムゾーンの一覧は、 list of time zones を参照してください。
\n\nこれは必ずしもサーバのタイムゾーンではないことに注意してください。たとえば、1 つのサーバ内に Django 製のサイトがあり、それぞれが異なるタイムゾーン設定を持つこともできます。
\nUSE_TZ が False のとき、これは Django が日時を保持するタイムゾーンとなります。USE_TZ が True のとき、これは Django がテンプレート内で日時を表示するため、およびフォーム内で入力された日時を解釈するために使う、デフォルトのタイムゾーンです。
Unix 環境 (ここで time.tzset() が実装されている場合)では、Djangoは os.environ['TZ'] 変数を TIME_ZONE 設定で指定したタイムゾーンに設定します。したがって、すべてのビューとモデルは自動的にこのタイムゾーンで動作します。しかし、 手動で設定を行う で説明されているような手動設定オプションを使用している場合は、Djangoは TZ 環境変数を設定しません。Djangoが TZ 環境変数を設定しない場合は、プロセスが正しい環境で実行されていることを確認するのはあなたの責任です。
USE_BLANK_CHOICE_DASHLink to this heading#デフォルト値: False
The default blank choice label in Select widgets was changed from\n"---------" to django.db.models.fields.BLANK_CHOICE_LABEL. Set this\ntransitional setting to True to revert to the previous label.
USE_I18NLink to this heading#デフォルト値: True
Djangoの翻訳システムを有効にするかどうかを指定する真偽値です。パフォーマンスのためにオフにする方法を提供します。これが False に設定されている場合、Djangoは翻訳システムを読み込まないように一部の最適化を行います。
関連項目: LANGUAGE_CODE および USE_TZ
USE_THOUSAND_SEPARATORLink to this heading#デフォルト値: False
真偽値で、数値を 1,000 単位で表示するかどうかを指定します。 True に設定すると、Django は数値を NUMBER_GROUPING と THOUSAND_SEPARATOR の設定に従ってフォーマットします。最後の 2 つの設定はロケールによっても決定される可能性があり、そちらが優先されます。
関連項目: DECIMAL_SEPARATOR, NUMBER_GROUPING, THOUSAND_SEPARATOR
USE_TZLink to this heading#デフォルト値: True
デフォルトで日時がタイムゾーンを意識するかどうかを指定する真偽値です。これが True に設定されている場合、Django は内部的にタイムゾーンを意識した日時を使用します。
USE_TZ が False の場合、Django はローカルタイムで naive な日時を使用しますが、ISO 8601 形式の文字列を解析するときには、タイムゾーン情報が存在すれば常に保持されます。
USE_X_FORWARDED_HOSTLink to this heading#デフォルト値: False
X-Forwarded-Host ヘッダを Host ヘッダより優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合にのみ有効化すべきです。
この設定は USE_X_FORWARDED_PORT よりも優先されます。RFC 7239 Section 5.3 によると、X-Forwarded-Host ヘッダにはポート番号を含めることができるため、その場合は USE_X_FORWARDED_PORT を使用すべきではありません。
USE_X_FORWARDED_PORTLink to this heading#デフォルト値: False
X-Forwarded-Port ヘッダを SERVER_PORT META 変数より優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合のみ、これを有効にするべきです。
この設定より USE_X_FORWARDED_HOST の方が優先されます。
URLIZE_ASSUME_HTTPSLink to this heading#デフォルト値: False
Set this transitional setting to True to opt into using HTTPS as the\ndefault protocol when none is provided in URLs processed by the\nurlize and urlizetrunc template filters during the Django\n6.x release cycle.
WSGI_APPLICATIONLink to this heading#デフォルト値: None
Djangoの組み込みサーバー (例えば runserver) が使用するWSGIアプリケーションオブジェクトの完全なPythonパスです。django-admin startproject 管理コマンドは標準の wsgi.py ファイルを作成し、その中に application 呼び出し可能オブジェクトを含め、この設定をその application にポイントします。
設定されていない場合は、 django.core.wsgi.get_wsgi_application() の返り値が使用されます。この場合、runserver の動作は以前のDjangoバージョンと同一になります。
YEAR_MONTH_FORMATLink to this heading#デフォルト値: 'F Y'
Django管理サイトのチェンジリストページで、年と月のみが表示される場合に、デフォルトの日付フィールドの書式設定を使用する方法。そして、システムの他の部分でも同様に適用される可能性があります。
\nたとえば、Djangoの管理画面のチェンジリストページが日付で絞り込まれている場合、指定された月のヘッダーには月と年が表示されます。異なるロケールには異なる形式があります。例えば、米国英語では「January 2006」と表示されますが、別のロケールでは「2006/January」のように表示されるかもしれません。
\n対応するロケールによる書式が優先され、適用されることに留意してください。
\n許可される日付フォーマット文字列については、 使用可能な日付フォーマット文字列 を参照してください。また、 DATE_FORMAT 、 DATETIME_FORMAT 、 TIME_FORMAT および MONTH_DAY_FORMAT も参照してください。
X_FRAME_OPTIONSLink to this heading#デフォルト値: 'DENY'
XFrameOptionsMiddleware によって使用される X-Frame-Options ヘッダのデフォルト値については、クリックジャッキング保護 のドキュメントを参照してください。
AUTHENTICATION_BACKENDSLink to this heading#デフォルト値: ['django.contrib.auth.backends.ModelBackend']
ユーザーを認証しようとするときに使用する認証バックエンドクラスのリスト（文字列形式）。詳細については 認証バックエンドのドキュメント を参照してください。
\nAUTH_USER_MODELLink to this heading#デフォルト値: 'auth.User'
User を表すために使うモデルです。カスタムの User モデルを置き換える を参照してください。
\n\nLOGIN_REDIRECT_URLLink to this heading#デフォルト値: '/accounts/profile/'
LoginView が next GET パラメータを受け取らないときにログイン後にリダイレクトされる URL または 名前付き URL パターン 。
LOGIN_URLLink to this heading#デフォルト値: '/accounts/login/'
login_required() デコレータ、LoginRequiredMixin、AccessMixin を使っているとき、または LoginRequiredMiddleware ミドルウェアがインストールされている場合に、ログインのためにリダイレクトされる URL または 名前付き URL パターン です。
LOGOUT_REDIRECT_URLLink to this heading#デフォルト値: None
リクエストがログアウト後にリダイレクトされるURLまたは 名前付きURLパターン で、 LogoutView が next_page 属性を持っていない場合に使用されます。
None の場合、リダイレクトは行われず、ログアウトビューがレンダリングされます。
PASSWORD_RESET_TIMEOUTLink to this heading#デフォルト値: 259200 (秒単位で、3日)
パスワードリセットリンクの有効期間 (秒単位)。
\nPasswordResetConfirmView によって使用されます。
PASSWORD_HASHERSLink to this heading#関連項目: Djangoのパスワード保存方法
\nデフォルト値:
\n[\n "django.contrib.auth.hashers.PBKDF2PasswordHasher",\n "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",\n "django.contrib.auth.hashers.Argon2PasswordHasher",\n "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",\n "django.contrib.auth.hashers.ScryptPasswordHasher",\n]\nAUTH_PASSWORD_VALIDATORSLink to this heading#デフォルト値: [] (空のリスト)
ユーザーのパスワードの強度をチェックするために使用されるバリデータのリストです。詳細については パスワードの妥当性検証 を参照してください。デフォルトでは、バリデーションは実行されず、すべてのパスワードが受け入れられます。
\nMESSAGE_LEVELLink to this heading#デフォルト値: messages.INFO
メッセージフレームワークによって記録されるメッセージレベルの最小値を設定します。 詳細については、 メッセージレベル を参照してください。
\n\nMESSAGE_STORAGELink to this heading#デフォルト値: 'django.contrib.messages.storage.fallback.FallbackStorage'
Django がメッセージデータをどこに保存するかを制御します。有効な値は次の通りです:
\n'django.contrib.messages.storage.fallback.FallbackStorage'
'django.contrib.messages.storage.session.SessionStorage'
'django.contrib.messages.storage.cookie.CookieStorage'
詳細については、 メッセージストレージバックエンド を参照してください。
\nCookieを使用するバックエンド -- CookieStorage および FallbackStorage -- は、クッキーを設定する際に SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY の値を使用します。
SESSION_CACHE_ALIASLink to this heading#デフォルト値: 'default'
キャッシュベースのセッションストレージ を使用している場合、これによって使用するキャッシュが選択されます。
\nSESSION_ENGINELink to this heading#デフォルト値: 'django.contrib.sessions.backends.db'
Djangoがセッションデータを保存する場所を制御します。含まれているエンジンには、以下があります:
\n'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'
詳細は セッションエンジンを設定する を参照してください。
\nSESSION_EXPIRE_AT_BROWSER_CLOSELink to this heading#デフォルト値: False
ユーザーがブラウザを閉じたときにセッションを終了させるかどうか。 ブラウザ起動中のみ有効なセッション vs. 永続的なセッション を参照してください。
\nSESSION_FILE_PATHLink to this heading#デフォルト値: None
ファイルベースのセッションストレージを使用している場合、この設定は Django がセッションデータを格納するディレクトリを設定します。デフォルト値 (None) が使用される場合、Django はシステムの標準的な一時ディレクトリを使用します。
SESSION_SAVE_EVERY_REQUESTLink to this heading#デフォルト値: False
すべてのリクエストにおいてセッションデータを保存するかどうか。これが False (デフォルト) の場合、セッションデータは変更された場合にのみ保存されます。つまり、その辞書の値に何らかの代入や削除が行われた場合です。この設定が有効であっても、空のセッションは作成されません。
SESSION_SERIALIZERLink to this heading#デフォルト値: 'django.contrib.sessions.serializers.JSONSerializer'
セッションデータのシリアライズに使用するシリアライザクラスの完全なインポートパスです。含まれているシリアライザは次のとおりです:
\n'django.contrib.sessions.serializers.JSONSerializer'
詳細については、 セッションのシリアライズ を参照してください。
\ndjango.contrib.sites の設定。
SITE_IDLink to this heading#デフォルト値: 定義されていません
\ndjango_site データベーステーブルの現在のサイトの ID（整数）です。これを使用することで、アプリケーションデータが特定のサイトにフックでき、単一のデータベースで複数のサイトのコンテンツを管理できます。
django.contrib.staticfiles の設定。
STATIC_ROOTLink to this heading#デフォルト値: None
collectstatic がデプロイメント用に静的ファイルを収集するディレクトリの絶対パスです。
例: "/var/www/example.com/static/"
staticfiles contrib アプリが有効になっている場合（デフォルトのプロジェクトテンプレートにあるように）、 collectstatic 管理コマンドは静的ファイルをこのディレクトリに収集します。使用法についての詳細は、 静的ファイルの管理 のHow-toをご覧ください。
STATIC_URLLink to this heading#デフォルト値: None
STATIC_ROOT に位置する静的ファイルを参照する際に使用する URL。
例: "static/" または "https://static.example.com/"
None でない場合、これは アセット定義 (Media クラス) および staticfiles アプリ において基本パスとして使用されます。
空でない値に設定されている場合、スラッシュで終わらなければなりません。
\nこれらのファイルを開発環境で提供するためには 設定が必要になるかもしれません し、本番環境では間違いなくそうする必要があります 本番環境 。
\n\nSTATICFILES_DIRSLink to this heading#デフォルト値: [] (空のリスト)
この設定は FileSystemFinder のファインダーが有効になっている場合に staticfiles アプリが通過する追加の場所を定義します。たとえば、collectstatic や findstatic 管理コマンドを使用している場合や、 静的ファイル提供ビューを使用している場合などです。
これは、追加のファイルディレクトリへのフルパスを含む文字列のリストに設定する必要があります。例:
\nSTATICFILES_DIRS = [\n "/home/special.polls.com/polls/static",\n "/home/polls.com/polls/static",\n "/opt/webfiles/common",\n]\nこれらのパスは、WindowsでもUnixスタイルのスラッシュを使用する必要があることに注意してください（例： "C:/Users/user/mysite/extra_static_content" ）。
追加の名前空間である場所の一つを参照したい場合、 オプションで (prefix, path) の形のタプルとしてプレフィックスを提供できます。例えば:
STATICFILES_DIRS = [\n # ...\n ("downloads", "/opt/webfiles/stats"),\n]\nたとえば、STATIC_URL を 'static/' に設定しているとします。この場合、 collectstatic 管理コマンドは、 STATIC_ROOT の 'downloads' サブディレクトリ内の "stats" ファイルを収集します。
これにより、テンプレート内でローカルファイル '/opt/webfiles/stats/polls_20101022.tar.gz' を '/static/downloads/polls_20101022.tar.gz' として参照できるようになります。例えば：
<a href="{% static 'downloads/polls_20101022.tar.gz' %}">\nSTATICFILES_FINDERSLink to this heading#デフォルト値:
\n[\n "django.contrib.staticfiles.finders.FileSystemFinder",\n "django.contrib.staticfiles.finders.AppDirectoriesFinder",\n]\n様々な場所にある静的ファイルを見つける方法を知っているファインダーバックエンドのリストです。
\nデフォルトでは、 STATICFILES_DIRS 設定で指定された場所に保存されているファイル（ django.contrib.staticfiles.finders.FileSystemFinder を使用して）と、各アプリの static サブディレクトリにあるファイル（ django.contrib.staticfiles.finders.AppDirectoriesFinder を使用して）を見つけます。同じ名前のファイルが複数存在する場合、最初に見つかったファイルが使用されます。
デフォルトで無効になっているファインダーが 1 つあります: django.contrib.staticfiles.finders.DefaultStorageFinder 。これを STATICFILES_FINDERS 設定に追加すると、 STORAGES 設定の default キーで定義されたデフォルトファイルストレージ内の静的ファイルを探します。
静的ファイルファインダーは現在、プライベートインターフェースとみなされており、このインターフェースはドキュメント化されていません。
\ni18n/l10n)Link to this heading#i18n)Link to this heading#l10n)Link to this heading#セキュリティ
\n\nクロスサイトリクエストフォージェリ (CSRF) 保護
\n\nデータベース: テスト