Getting Help

el
en
es
fr
id
it
ko
pl
pt-br
zh-hans
言語: ja

1.10
1.11
2.0
2.1
2.2
3.0
3.1
3.2
4.0
4.1
4.2
5.0
dev
ドキュメントのバージョン: 5.1

設定¶

警告

設定を上書きするとき、特にデフォルト値が空でないリストや辞書の場合、例えば STATICFILES_FINDERS などは、注意してください。Djangoの使用したい機能に必要なコンポーネントを保持するようにしてください。

コアの設定 ¶

ここでは、Django の core で利用できる設定とそのデフォルト値をリストしました。contrib アプリで提供される設定のリストは、core の設定のトピックのインデックスの下にあります。入門的な資料については、 settings のトピックガイドを参照してください。

`ABSOLUTE_URL_OVERRIDES`¶

デフォルト値: {} (空の辞書)

"app_label.model_name" 文字列をモデルオブジェクトを受け取り、その URL を返す関数へのマッピングを行う辞書です。これは、インストールごとに get_absolute_url() メソッドを挿入またはオーバーライドする方法です。例：

ABSOLUTE_URL_OVERRIDES = {
    "blogs.blog": lambda o: "/blogs/%s/" % o.slug,
    "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

この設定で使用するモデル名は、実際のモデルクラス名の大文字小文字に関わらず、すべて小文字である必要があります。

`ADMINS`¶

デフォルト値: [] (空のリスト)

コードエラー通知を受け取る全ての人々のリストです。 DEBUG=False が設定され、 AdminEmailHandler が LOGGING に設定されている場合（デフォルトで設定されています）、Djangoはこれらの人々にリクエスト/レスポンスサイクルで発生した例外の詳細をメールで送信します。

リスト内の各項目は、(フルネーム、メールアドレス) のタプルである必要があります。例:

[("John", "john@example.com"), ("Mary", "mary@example.com")]

`ALLOWED_HOSTS`¶

デフォルト値: [] (空のリスト)

Django サイトを配信できるホスト/ドメイン名を表す文字列のリストです。これはセキュリティ対策の手段の1つで、一見安全な設定の Web サーバでも晒される可能性が高い、 HTTP Host header 攻撃を防ぐことができます。

このリスト中の値は完全修飾名 (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 の検証機でそれを取り除きます。

Host ヘッダ (と USE_X_FORWARDED_HOST が有効な場合は X-Forwarded-Host) が、このリストのどれとも一致しない場合、 django.http.HttpRequest.get_host() は SuspiciousOperation 例外を起こします。

DEBUG が True であり、かつ ALLOWED_HOSTS が空の場合、ホストは ['.localhost', '127.0.0.1', '[::1]'] に対して検証されます。

ALLOWED_HOSTS は、テストを実行する際にもチェックされます。

このヘッダの検証は get_host() メソッドの実行時にのみ適用されます。もし request.META から直接 Host ヘッダにアクセスするコードを書いてしまうと、このセキュリティプロテクションを回避してしまうので注意してください。

`APPEND_SLASH`¶

デフォルト値: True

True に設定すると、リクエスト URL が URLconf 内のどのパターンにもマッチせず、/ で終わっていなかった場合に、末尾に / を追加した URL への HTTP リダイレクトを発行します。ただし、リダイレクトすると POST リクエストで送信するデータが失われることがあるので注意が必要です。

APPEND_SLASH 設定は CommonMiddleware がインストールされているときのみ有効です。詳しくは see ミドルウェア (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.PyMemcacheCache'
'django.core.cache.backends.memcached.PyLibMCCache'
'django.core.cache.backends.redis.RedisCache'

Django に同梱されていないキャッシュ用バックエンドを使用する時は、BACKEND にバックエンドのクラスの完全修飾パス (例: mypackage.backends.whatever.WhateverCache) を設定してください。

`KEY_FUNCTION`¶

ドット区切りパスを含む文字列で、プレフィックス、バージョン、キーを最終的なキャッシュキーに組み合わせる方法を定義する関数（または任意の呼び出し可能オブジェクト）を指します。デフォルトの実装は次の関数と同等です:

def make_key(key, key_prefix, version):
    return ":".join([key_prefix, str(version), key])

好きなキー関数を使用できますが、同じ引数のシグネチャを持つことが条件です。

詳細はキャッシュのドキュメントを参照してください。

`KEY_PREFIX`¶

デフォルト値: '' (空文字列)

Djangoサーバーで使用されるすべてのキャッシュキーにデフォルトで自動的に追加（先頭に付けられる）される文字列。

詳細はキャッシュのドキュメントを参照してください。

`LOCATION`¶

デフォルト値: '' (空文字列)

使用するキャッシュの位置。これはファイルシステムキャッシュ用のディレクトリ、memcacheサーバーのホストとポート、またはローカルメモリキャッシュの識別名などが該当します。例:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}

`OPTIONS`¶

デフォルト値: None

キャッシュバックエンドに渡す追加パラメータ。利用可能なパラメータは、使用しているキャッシュバックエンドによって異なります。

利用可能なパラメータに関する情報は、キャッシュ式数のドキュメントに記載されています。詳細については、バックエンドモジュールの独自のドキュメントを参照してください。

`TIMEOUT`¶

デフォルト値: 300

キャッシュエントリが古いとみなされるまでの秒数。この設定の値が None である場合、キャッシュエントリは期限切れになりません。値が 0 の場合、キーは即座に期限切れになります（実質的に「キャッシュしない」）。

`VERSION`¶

デフォルト値: 1

Django サーバーによって生成されるキャッシュキーのデフォルトのバージョン番号。

詳細はキャッシュのドキュメントを参照してください。

`CACHE_MIDDLEWARE_ALIAS`¶

デフォルト値: 'default'

キャッシュミドルウェアに使用するキャッシュ接続。

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

デフォルト値: '' (空文字列)

キャッシュキーの生成時にキャッシュミドルウェアからプレフィックスとして追加される文字列です。このプレフィックスは KEY_PREFIX 設定と組み合わされます。それを置き換えるものではありません。

Django のキャッシュフレームワークを参照。

`CACHE_MIDDLEWARE_SECONDS`¶

デフォルト値: 600

キャッシュミドルウェア用のページをキャッシュするデフォルトの秒数。

Django のキャッシュフレームワークを参照。

`CSRF_USE_SESSIONS`¶

デフォルト値: False

ユーザーのセッション内にCSRFトークンをCookieではなく保存するかどうか。これを使用するには、 django.contrib.sessions の使用が必要です。

CSRF トークンをクッキーに保存する（Django のデフォルト）は安全ですが、他のウェブフレームワークではセッションに保存することが一般的であり、そのためセキュリティ監査員によってしばしば要求されます。

デフォルトのエラービューが CSRF トークンを必要とするため、CSRF_USE_SESSIONS を使用している場合、エラービューをトリガーする可能性のある例外（例えば PermissionDenied など）を引き起こす可能性があるミドルウェアよりも前に、 SessionMiddleware が MIDDLEWARE に登録されている必要があります。 Middleware の順序を参照してください。

`CSRF_FAILURE_VIEW`¶

デフォルト値: 'django.views.csrf.csrf_failure'

CSRF保護によって受信リクエストが拒否された場合に使用されるビュー関数へのドット区切りパス。関数には次のシグネチャが必要です:

def csrf_failure(request, reason=""): ...

reason は、リクエストが拒否された理由を示す短いメッセージ（開発者やログ用であり、エンドユーザー向けではありません）です。これは HttpResponseForbidden を返すべきです。

django.views.csrf.csrf_failure() は追加の template_name パラメータを受け付け、デフォルトでは '403_csrf.html' になっています。その名前のテンプレートが存在する場合、ページのレンダリングに使用されます。

`CSRF_HEADER_NAME`¶

デフォルト値: 'HTTP_X_CSRFTOKEN'

CSRF認証に使用されるリクエストヘッダーの名前。

request.META の他の HTTP ヘッダと同様に、サーバーから受信したヘッダ名は、すべての文字を大文字に変換し、ハイフンをアンダースコアに置き換え、名前に 'HTTP_' プレフィックスを追加することで正規化されます。たとえば、クライアントが 'X-XSRF-TOKEN' ヘッダを送信する場合、設定は 'HTTP_X_XSRF_TOKEN' であるべきです。

`CSRF_TRUSTED_ORIGINS`¶

デフォルト値: [] (空のリスト)

安全でないリクエスト (例: POST) のための信頼できるオリジンのリスト。

Origin ヘッダーを含むリクエストに対して、Django の CSRF 保護は、そのヘッダーが Host ヘッダーに存在するオリジンと一致することを要求します。

Origin ヘッダーを含まない secure でないリクエストには、Host ヘッダーに存在するオリジンと一致する Referer ヘッダーが必要です。

これらのチェックは、例えば、subdomain.example.com からの POST リクエストが api.example.com に対して成功するのを防ぎます。クロスオリジンで安全でないリクエストが必要な場合、例を続けると、このリストに 'https://subdomain.example.com' を追加してください（そして、リクエストが安全でないページから発生する場合は http://... も追加します）。

この設定はサブドメインもサポートしているので、例えば 'https://*.example.com' を追加することで、example.com の全サブドメインからのアクセスを許可できます。

`DATABASES`¶

デフォルト値: {} (空の辞書)

Django で使用される全てのデータベースの設定を含む辞書です。これは、データベースエイリアスを個々のデータベースのオプションを含む辞書にマッピングする内容のネストされた辞書です。

DATABASES 設定では、default データベースを設定する必要があります。追加で任意の数のデータベースを指定することもできます。

最もシンプルな設定ファイルは、SQLite を使用した単一データベース設定です。これは以下のように設定できます。

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "mydatabase",
    }
}

MariaDB、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

これを False に設定すると、 Djangoのトランザクション管理を無効にして、独自のトランザクション管理を実装したい場合に利用できます。

`ENGINE`¶

デフォルト値: '' (空文字列)

使用するデータベースバックエンドです。組み込みのデータベースバックエンドは次の通りです:

'django.db.backends.postgresql'
'django.db.backends.mysql'
'django.db.backends.sqlite3'
'django.db.backends.oracle'

Django に同梱されていないデータベースバックエンドを使用するには、ENGINE を完全修飾パス (例: mypackage.backends.whatever) に設定します。

`HOST`¶

デフォルト値: '' (空文字列)

データベースに接続する際に使用するホストです。空の文字列の場合は localhost を意味します。SQLite では使用されません。

この値がスラッシュ ('/') で始まり、MySQL を使用している場合、MySQL は指定されたソケットに Unix ソケット経由で接続します。例えば:

"HOST": "/var/run/mysql"

MySQLを使用している場合、この値がスラッシュで 始まらない 場合、この値はホストとみなされます。

PostgreSQL を使用している場合、デフォルトでは (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 を定義する必要があります。

`NAME`¶

デフォルト値: '' (空文字列)

使用するデータベースの名前。SQLite の場合、データベースファイルへのフルパスになります。パスを指定する場合は、Windows であっても常にスラッシュを使用してください（例: C:/homes/user/mysite/sqlite3.db ）。

`CONN_MAX_AGE`¶

デフォルト値: 0

データベース接続の寿命を秒単位の整数で指定します。各リクエストの終了時にデータベース接続を閉じる場合は 0 を使用します（Django の従来の動作）。無制限の永続的なデータベース接続の場合は None を使用します。

`CONN_HEALTH_CHECKS`¶

デフォルト値: False

もし True に設定されている場合、データベースアクセスを行う各リクエストで再利用される前に、既存の永続的なデータベース接続がヘルスチェックされます。ヘルスチェックが失敗した場合、接続は再確立され、データベースサーバーは新しい接続を受け入れ、提供する準備が整っているが、接続が使用できなくなったときにリクエストが失敗することはありません（例：データベースサーバーが再起動し、既存の接続を閉じた後）。

`OPTIONS`¶

デフォルト値: {} (空の辞書)

データベースに接続する際に使用する追加パラメータ。利用可能なパラメータは、使用しているデータベースバックエンドによって異なります。

利用可能なパラメータに関する情報は、データベースのバックエンドのドキュメントに記載されています。詳細については、バックエンドモジュール独自のドキュメントを参照してください。

`PASSWORD`¶

デフォルト値: '' (空文字列)

データベースに接続する際に使用するパスワード。SQLiteでは使用しません。

`PORT`¶

デフォルト値: '' (空文字列)

データベースに接続する際に使用するポート。空の文字列はデフォルトポートを意味します。SQLiteでは使用されません。

`TIME_ZONE`¶

デフォルト値: None

このデータベース接続のためのタイムゾーンを表す文字列、または None です。 DATABASES 設定のこの内部オプションは、一般的な TIME_ZONE 設定と同じ値を受け付けます。

USE_TZ が True のとき、データベースからの日時の読み込みは、タイムゾーンが None ではない場合はその値に、そうでない場合は UTC に設定された意識的な日時を返します。

USE_TZ が False の場合、このオプションを設定するとはエラーになります。

データベースバックエンドがタイムゾーンをサポートしていない場合（例えば SQLite、MySQL、Oracle など）、このオプションが設定されている場合は Django はローカルタイムで日時を読み書きし、設定されていない場合は UTC で行います。

接続のタイムゾーンを変更すると、データベースの読み書きに影響が出ます。
- Django がデータベースを管理しており、別の強い理由がない限り、このオプションを設定しないでおくべきです。UTC で日時を保存することが最善です。これにより、サマータイムの変更時に曖昧な日時や存在しない日時を回避できます。また、UTC で日時を受け取ることで、日時の計算が簡単になります。夏時間の移行時にオフセットの変化を考慮する必要がないからです。
- もしUTCではなくローカル時間で日時を保存するサードパーティーのデータベースに接続する場合は、このオプションを適切なタイムゾーンに設定する必要があります。同様に、Djangoがデータベースを管理しているが、サードパーティーシステムが同じデータベースに接続し、ローカル時間で日時を取得することを期待している場合は、このオプションを設定する必要があります。
データベースバックエンドがタイムゾーンをサポートしている場合（例えば、PostgreSQL）、データベース接続のタイムゾーンはこの値に設定されます。

TIME_ZONE オプションを設定する必要はほとんどありませんが、状況によっては必要になることがあります。特に、PostgreSQLの date_trunc() や generate_series() などの日時関数を使用するクエリに関わる場合、特にサマータイムの切り替えなど、時間ベースのシリーズを生成するときには、一般的な TIME_ZONE 設定と一致させることが推奨されます。

この値はいつでも変更可能であり、データベースは日時を設定されたタイムゾーンに変換します。

ただし、これには欠点があります。すべての日時をローカルタイムで受け取ると、日時の算術がより複雑になります。DST（サマータイム）の変更期間を考慮に入れる必要があります。

素のSQLクエリで TIME_ZONE オプションを設定する代わりに、AT TIME ZONE を使用して明示的にローカルタイムに変換することを検討してください。

`DISABLE_SERVER_SIDE_CURSORS`¶

デフォルト値: False

もし QuerySet.iterator() でサーバーサイドのカーソルの使用を無効にしたい場合は、これを True に設定してください。トランザクションプールとサーバーサイドカーソルには使用例が記載されています。

これは PostgreSQL 固有の設定です。

`USER`¶

デフォルト値: '' (空文字列)

データベースに接続する際に使用するユーザー名。SQLiteでは使用されません。

`TEST`¶

デフォルト値: {} (空の辞書)

テスト用データベースの設定辞書。テスト用データベースの作成と使用に関する詳細については、 test データベースを参照してください。

以下はテスト用データベースの設定例です:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "USER": "mydatabaseuser",
        "NAME": "mydatabase",
        "TEST": {
            "NAME": "mytestdatabase",
        },
    },
}

TEST 辞書で利用可能なキーは以下のとおりです:

`CHARSET`¶

デフォルト値: None

テストデータベースを作成する際に使用される文字セットエンコーディングです。この文字列の値はデータベースに直接渡されるため、その形式はバックエンドに依存します。

PostgreSQL (postgresql) および MySQL (mysql) バックエンドでサポートされています。

`COLLATION`¶

デフォルト値: None

テストデータベースを作成する際に使用する照合順序 (collation)。この値はバックエンドに直接渡されるため、その形式はバックエンドに依存します。

mysql バックエンドでのみサポートされています (MySQL manual を参照してください)。

`DEPENDENCIES`¶

デフォルト値: ['default'] で、 default 以外のすべてのデータベースには依存関係は設定されていません。

データベースの作成順序の依存関係です。詳細については、テストデータベースの作成順序を制御するドキュメントを参照してください。

`MIGRATE`¶

デフォルト値: True

False に設定されている場合、テストデータベースを作成するときにマイグレーションは実行されません。これは MIGRATION_MODULES に None を値として設定するのと似ていますが、すべてのアプリに適用されます。

`MIRROR`¶

デフォルト値: None

このデータベースがテスト中にミラーリングするべきデータベースのエイリアスです。トランザクションに依存しているため、 TestCase の代わりに TransactionTestCase 内で使用する必要があります。

この設定は、複数のデータベースのプライマリ/レプリカ (一部のデータベースではマスター/スレーブと呼ばれる) 構成のテストを可能にするために存在します。詳細については、プライマリ/レプリカ構成のテストのドキュメントを参照してください。

`NAME`¶

デフォルト値: None

テストスイートを実行する際に使用するデータベースの名前。

デフォルト値 (None) をSQLiteデータベースエンジンで使用すると、テストはメモリ内のデータベースを使用します。そのほかのデータベースエンジンでは、テストデータベースは 'test_' + DATABASE_NAME という名前が使われます。

テストデータベースを参照。

デフォルト値: '25M'

これは Oracle 固有の設定です。

空き領域が不足するときに DATAFILE_TMP が拡張される量。

`DATA_UPLOAD_MAX_MEMORY_SIZE`¶

デフォルト値: 2621440 (例: 2.5 MB)。

リクエストボディの最大サイズ (バイト単位) で、このサイズを超えると SuspiciousOperation (RequestDataTooBig) が発生します。このチェックは request.body や request.POST へのアクセス時に行われ、ファイルアップロードデータを除いた総リクエストサイズに対して計算されます。このチェックを無効にするためには、この値を None に設定できます。通常よりも大きなフォーム投稿を受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。

リクエストデータの量は、リクエストを処理しGETおよびPOST辞書を作成するのに必要なメモリ量に関連しています。大きなリクエストは、精査されていないままの場合、サービス妨害攻撃の手段として使用される可能性があります。通常、Webサーバーは深いリクエスト検査を行わないため、同様のチェックをそのレベルで行うことはできません。

関連項目: FILE_UPLOAD_MAX_MEMORY_SIZE

`DATA_UPLOAD_MAX_NUMBER_FIELDS`¶

デフォルト値: 1000

GET または POST 経由で受け取り可能なパラメータの最大数を超えると、 SuspiciousOperation (TooManyFields) が発生します。このチェックを無効にするには、これを None に設定してください。通常よりも多くのフォームフィールドを受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。

リクエストパラメータの数は、リクエストを処理して GET と POST の辞書を満たすために必要な時間と相関しています。大きなリクエストは、チェックされないままにしておくと、サービス拒否攻撃のベクトルとして使用される可能性があります。Webサーバは通常、深いリクエスト検査を行わないため、そのレベルで同様のチェックを行うことはできません。

`DATA_UPLOAD_MAX_NUMBER_FILES`¶

デフォルト値: 100

POSTで multipart/form-data エンコードされたリクエスト経由で受信できるファイルの最大数です。この数を超えると SuspiciousOperation (TooManyFiles) が発生します。このチェックを無効にするには、これを None に設定できます。通常よりも多くのファイルフィールドを受信することが予想されるアプリケーションは、この設定を調整する必要があります。

受け入れられるファイルの数は、リクエストを処理するために必要な時間とメモリに関連しています。大きなリクエストは、チェックなしに放置されると、サービス拒否攻撃のベクトルとして使用される可能性があります。Web サーバーは通常、リクエストの深い検査を行わないため、そのレベルで同様のチェックを行うことはできません。

`DATABASE_ROUTERS`¶

デフォルト値: [] (空のリスト)

データベースクエリを実行する際に使用されるデータベースを決定するために使用されるルーターのリスト。

複数データベース構成での自動データベースルーティングに関するドキュメントを参照してください。

`DATE_FORMAT`¶

デフォルト値: 'N j, Y' (例: Feb. 4, 2003)

システムのどの部分でも日付フィールドを表示する際に使用するデフォルトのフォーマット。ただし、ロケールによって指定されたフォーマットが優先され、代わりに適用されます。 使用可能な日付フォーマット文字列 を参照してください。

`DATE_INPUT_FORMATS`¶

デフォルト値:

[
    "%Y-%m-%d",  # '2006-10-25'
    "%m/%d/%Y",  # '10/25/2006'
    "%m/%d/%y",  # '10/25/06'
    "%b %d %Y",  # 'Oct 25 2006'
    "%b %d, %Y",  # 'Oct 25, 2006'
    "%d %b %Y",  # '25 Oct 2006'
    "%d %b, %Y",  # '25 Oct, 2006'
    "%B %d %Y",  # 'October 25 2006'
    "%B %d, %Y",  # 'October 25, 2006'
    "%d %B %Y",  # '25 October 2006'
    "%d %B, %Y",  # '25 October, 2006'
]

日付フィールドにデータを入力する際に受け入れられる形式のリストです。形式は順番に試され、最初の有効なものが使用されます。これらの形式文字列は、 date テンプレートフィルタからの形式文字列ではなく、Python の datetime モジュールの構文を使用していることに注意してください。

ロケールが指定するフォーマットが優先され、代わりに適用されます。

`DATETIME_FORMAT`¶

デフォルト値: 'N j, Y, P' (例: Feb. 4, 2003, 4 p.m.)

システムのどの部分で日時フィールドを表示する際に使用するデフォルトのフォーマット。ロケールで指定されたフォーマットの方が優先され、代わりに適用されることに注意してください。許可される日付フォーマット文字列については、 使用可能な日付フォーマット文字列 を参照してください。

`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'
    "%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 %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'
]

日時フィールドにデータを入力する際に受け入れられるフォーマットのリスト。フォーマットは順番に試され、最初の有効なものが使用されます。これらのフォーマット文字列は、date テンプレートフィルタからのフォーマット文字列ではなく、Python の datetime モジュールの構文を使用することに注意してください。日付のみのフォーマットは含まれていません。というのも、datetime フィールドは最終手段として自動的に DATE_INPUT_FORMATS を試みるからです。

ロケールが指定するフォーマットが優先され、代わりに適用されます。

関連項目: DATE_INPUT_FORMATS および TIME_INPUT_FORMATS を参照。

`DEBUG`¶

デフォルト値: False

デバッグモードをオン/オフにする真偽値です。

DEBUG をオンにした状態でサイトを本番環境にデプロイしないでください。

デバッグモードの主な特徴の一つは、詳細なエラーページの表示です。あなたのアプリが DEBUG が True のときに例外を発生させた場合、Djangoは詳細なトレースバックを表示します。これには、settings.py から現在定義されているすべてのDjango設定など、環境に関する多くのメタデータが含まれています。

セキュリティ対策として、Djangoでは SECRET_KEY のような機密性の高い設定を 含めない ことにしています。具体的には、以下のいずれかを含む名前の設定は除外されます:

'API'
'KEY'
'PASS'
'SECRET'
'SIGNATURE'
'TOKEN'

これらは 部分一致 であることに注意してください。 'PASS' は PASSWORD にも一致し、 'TOKEN' は TOKENIZED にも一致します。

それでも、デバッグ出力のセクションには、公開に適さないものが常に存在することに注意してください。ファイルパス、設定オプションなどは、攻撃者にサーバーについての追加情報を提供してしまいます。

また、DEBUG をオンにして実行している場合、Djangoは実行するすべてのSQLクエリを記憶します。デバッグ時に便利ですが、本番サーバーでは急速にメモリを消費します。

最後に、DEBUG が False の場合は、ALLOWED_HOSTS も適切に設定する必要があります。これを怠ると、すべてのリクエストが "Bad Request (400)" として返されます。

注釈

django-admin startproject によって作成されるデフォルトの settings.py ファイルは、利便性のために DEBUG = True に設定されています。

`DEBUG_PROPAGATE_EXCEPTIONS`¶

デフォルト値: False

True に設定されている場合、Djangoのビュー関数の例外処理 (handler500 、または DEBUG が True の場合はデバッグビュー) と500レスポンスのログ記録 (django.request) がスキップされ、例外は上に伝播します。

これは、一部のテスト設定で役立つ場合があります。Django の代わりに Web サーバーが "Internal Server Error" のレスポンスを生成することを望む場合を除いて、ライブサイトで使用するべきではありません。その場合、サーバーがレスポンスでスタックトレースやその他の機密情報を表示しないようにしてください。

`DECIMAL_SEPARATOR`¶

デフォルト値: '.' (ドット)

小数をフォーマットする際に使用されるデフォルトの小数点区切り記号です。

ロケールが指定する形式が優先され、それが適用されるので注意してください。

`DEFAULT_AUTO_FIELD`¶

デフォルト値: 'django.db.models.AutoField'

フィールドに primary_key=True の属性がないモデルに使用するデフォルトのプライマリキーのフィールドタイプ。

自動生成された中間テーブルをマイグレーションする

新しい自動生成された多対多のリレーションシップ用の through テーブルを作成する際には、DEFAULT_AUTO_FIELD の値が尊重されます。

残念ながら、現在はマイグレーションフレームワークで自動作成された中間テーブルのプライマリキーを更新することはできません。

これは、DEFAULT_AUTO_FIELD の値を切り替えてマイグレーションを生成した場合、リレーション先モデルのプライマリキーと中間テーブルからの外部キーは更新されますが、自動作成された中間テーブルのプライマリキーはマイグレーションされないことを意味します。

これを解決するには、必要な ALTER TABLE ステップを実行するために、マイグレーションに RunSQL 操作を追加する必要があります。既存のテーブル名は、sqlmigrate、dbshell、またはフィールドの remote_field.through._meta.db_table プロパティを介して確認できます。

モデルで明示的に定義されているものは、既にマイグレーションシステムで処理されています。

既存の自動生成された中間テーブルのプライマリキーに対して自動的なマイグレーションを許可する機能は、将来実装されるかもしれません #<32674> 。

`DEFAULT_CHARSET`¶

デフォルト値: 'utf-8'

手動で MIME タイプが指定されていない場合に、全ての HttpResponse オブジェクトで使用するデフォルトの文字セット。Content-Type ヘッダを構築する際に使用されます。

`DEFAULT_EXCEPTION_REPORTER`¶

デフォルト値: 'django.views.debug.ExceptionReporter'

まだ HttpRequest インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポータークラス。カスタムエラーレポートを参照してください。

`DEFAULT_EXCEPTION_REPORTER_FILTER`¶

デフォルト値: 'django.views.debug.SafeExceptionReporterFilter'

まだ HttpRequest インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポートフィルタクラス。エラーレポートのフィルタリングを参照してください。

`DEFAULT_FROM_EMAIL`¶

デフォルト値: 'webmaster@localhost'

サイト管理者からの自動対応用のデフォルトのメールアドレスです。このアドレスは送信メールの From: ヘッダに使用され、選択したメール送信プロトコルで有効なあらゆる形式を取ることができます。

これは ADMINS と MANAGERS へ送信されるエラーメッセージには影響しません。それについては SERVER_EMAIL を参照してください。

`DEFAULT_INDEX_TABLESPACE`¶

デフォルト値: '' (空文字列)

バックエンドがサポートしている場合 (テーブル空間（tablespace）を参照)、指定されていないフィールドのインデックスに使用するデフォルトのテーブル空間です。

`DEFAULT_TABLESPACE`¶

デフォルト値: '' (空文字列)

バックエンドがサポートしている場合、指定していないモデル用に使用するデフォルトのテーブル空間 (テーブル空間（tablespace）を参照)。

`DISALLOWED_USER_AGENTS`¶

デフォルト値: [] (空のリスト)

どのページも訪れることを許可されていないユーザーエージェント文字列を表すコンパイル済み正規表現オブジェクトのリスト。これはボット/クローラー用です。 CommonMiddleware がインストールされている場合にのみ使用されます（詳細は、ミドルウェア (Middleware) を参照）。

`EMAIL_BACKEND`¶

デフォルト値: 'django.core.mail.backends.smtp.EmailBackend'

使用するメール送信のバックエンド。利用可能なバックエンドのリストについては、メールのバックエンドを参照してください。

`EMAIL_FILE_PATH`¶

デフォルト値: 定義されていません

ファイルメールバックエンドが出力ファイルを保存するために使用するディレクトリ。

`EMAIL_HOST`¶

デフォルト値: 'localhost'

E メール送信に使われるホストです。

EMAIL_PORT も参照してください。

`EMAIL_HOST_PASSWORD`¶

デフォルト値: '' (空文字列)

EMAIL_HOST 内で定義された SMTP サーバで使われるパスワードです。この設定は、STMP サーバへの認証の際に EMAIL_HOST_USER と組み合わせて用いられます。どちらかの設定が空の場合、Django は認証を試みません。

EMAIL_HOST_USER も参照してください。

`EMAIL_HOST_USER`¶

デフォルト値: '' (空文字列)

`EMAIL_SSL_CERTFILE`¶

デフォルト値: None

If EMAIL_USE_SSL or EMAIL_USE_TLS is True and the secure connection to the SMTP server requires client authentication, use this setting to specify the path to a PEM-formatted certificate chain file, which must be used in conjunction with EMAIL_SSL_KEYFILE.

EMAIL_SSL_CERTFILE should not be used with a self-signed server certificate or a certificate from a private certificate authority (CA). In such cases, the server's certificate (or the root certificate of the private CA) should be installed into the system's CA bundle. This can be done by following platform-specific instructions for installing a root CA certificate, or by using OpenSSL's SSL_CERT_FILE or SSL_CERT_DIR environment variables to specify a custom certificate bundle (if modifying the system bundle is not possible or desired).

For more complex scenarios, the SMTP EmailBackend can be subclassed to add root certificates to its ssl_context using ssl.SSLContext.load_verify_locations().

`EMAIL_SSL_KEYFILE`¶

デフォルト値: None

If EMAIL_USE_SSL or EMAIL_USE_TLS is True, you can optionally specify the path to a PEM-formatted private key file for client authentication of the SSL connection along with EMAIL_SSL_CERTFILE.

EMAIL_SSL_CERTFILE と EMAIL_SSL_KEYFILE を設定しても、いかなる証明書のチェックも行われません。これらは基礎となる SSL 接続に渡されます。証明書チェーンファイルと秘密鍵ファイルの取り扱いの詳細については、Python の ssl.SSLContext.wrap_socket() 関数のドキュメントを参照してください。

`EMAIL_TIMEOUT`¶

デフォルト値: None

接続試行のような操作をブロックするためのタイムアウトを秒で指定します。

`FILE_UPLOAD_HANDLERS`¶

デフォルト値:

[
    "django.core.files.uploadhandler.MemoryFileUploadHandler",
    "django.core.files.uploadhandler.TemporaryFileUploadHandler",
]

アップロードに使用するハンドラのリストです。この設定を変更すると、Djangoのアップロードプロセスを完全にカスタマイズできます。代替も可能です。

詳細はファイルの管理を参照してください。

`FILE_UPLOAD_MAX_MEMORY_SIZE`¶

デフォルト値: 2621440 (例: 2.5 MB)。

ファイルシステムにストリーミングされる前のアップロードの最大サイズ（バイト単位）。詳細は、ファイルの管理を参照してください。

関連項目: DATA_UPLOAD_MAX_MEMORY_SIZE

`FILE_UPLOAD_DIRECTORY_PERMISSIONS`¶

デフォルト値: None

ファイルのアップロードの過程で作成されるディレクトリに適用する数値モード。

この設定は、 collectstatic 管理コマンドを使用する際の、収集された静的ディレクトリのデフォルト権限も決定します。それを上書きする方法の詳細については、 collectstatic を参照してください。

この値には FILE_UPLOAD_PERMISSIONS 設定の機能と同様の注意点があります。

`FILE_UPLOAD_PERMISSIONS`¶

デフォルト値: 0o644

新しくアップロードされたファイルに設定する数値モード（例えば 0o644 ）です。これらのモードが何を意味するのかについての詳細は、 os.chmod() のドキュメントを参照してください。

もし None なら、OS 依存の動作が得られます。ほとんどのプラットフォームでは、一時ファイルは 0o600 のモードを持ち、メモリから保存されるファイルはシステムの標準の umask を使用して保存されます。

セキュリティ上の理由から、これらの権限は FILE_UPLOAD_TEMP_DIR に保存される一時ファイルには適用されません。

この設定は、collectstatic 管理コマンドを使用して静的ファイルを収集する際のデフォルト権限も決定します。それをオーバーライドする方法については、 collectstatic を参照してください。

警告

モードは常に 0o で始めてください。

ファイルモードに慣れていない場合は、 0o プレフィックスが非常に重要であることに注意してください。これは8進数を示しており、モードを指定する際にはこの方法を使用しなければなりません。644 を使用しようとすると、全く正しくない動作になってしまいます。

`FILE_UPLOAD_TEMP_DIR`¶

デフォルト値: None

ファイルをアップロードしている間にデータ (通常は FILE_UPLOAD_MAX_MEMORY_SIZE より大きなファイル) を一時的に保存するディレクトリ。None の場合、Djangoはオペレーティングシステムの標準的な一時ディレクトリを使用します。たとえば、これは *nix スタイルのオペレーティングシステムではデフォルトで /tmp になります。

詳細はファイルの管理を参照してください。

`FIRST_DAY_OF_WEEK`¶

デフォルト値: 0 (日曜日)

週の最初の日を表す数字。カレンダーを表示する際に特に役立ちます。この値は、フォーマットの国際化が行われていない場合や、現在のロケールに対応するフォーマットが見つからない場合にのみ使用されます。

値は0から6までの整数でなければなりません。0は日曜日、1は月曜日、以降も同様です。

`FIXTURE_DIRS`¶

デフォルト値: [] (空のリスト)

フィクスチャファイルを検索するために、各アプリケーションの fixtures ディレクトリに加えて検索されるディレクトリのリスト。検索順。

これらのパスは、Windows でも Unix スタイルのスラッシュ (/) を使う必要があります。

フィクスチャでデータを投入するとフィクスチャのロードを参照してください。

`FORCE_SCRIPT_NAME`¶

デフォルト値: None

None でない場合、これはHTTPリクエストにおける SCRIPT_NAME 環境変数の値として使用されます。この設定により、サーバーが提供する SCRIPT_NAME の値を上書きできます（好きな値に書き換えることもできますし、何も提供しなくても構いません）。また、これはリクエスト/レスポンスサイクルの外部（例えば、管理コマンドやスタンドアロンのスクリプト）でURLリゾルバースクリプトのプレフィックスを設定するために django.setup() によって使用され、FORCE_SCRIPT_NAME が提供されたときに正しいURLを生成します。

`FORM_RENDERER`¶

デフォルト値: 'django.forms.renderers.DjangoTemplates'

フォームやフォームウィジェットをレンダリングするクラスです。低レベルレンダリングAPI を実装する必要があります。含まれるフォームレンダラは次の通りです。

`FORMS_URLFIELD_ASSUME_HTTPS`¶

New in Django 5.0.

バージョン 5.0 で非推奨.

デフォルト値: False

この移行用設定を True に設定し、Django 5.x リリースサイクル中に新しいデフォルト値 "https" を使用するように URLField.assume_scheme の設定を変更するオプションを選択します。

`FORMAT_MODULE_PATH`¶

デフォルト値: None

プロジェクトのロケールに対するカスタムフォーマット定義を含むPythonパッケージへの完全なPythonパス。None でない場合、Djangoは現在のロケールとして名付けられたディレクトリの下にある formats.py ファイルをチェックし、このファイルで定義されているフォーマットを使用します。

フォーマットの定義があるディレクトリ名は、locale name 表記を使用した名前であることが期待されます。たとえば、de、pt_BR、en_US などです。

たとえば、FORMAT_MODULE_PATH が mysite.formats に設定され、現在の言語が en (英語) である場合、Djangoは次のようなディレクトリ構造を期待します:

mysite/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py

この設定には、Python のパスのリストを設定することもできます。たとえば:

FORMAT_MODULE_PATH = [
    "mysite.formats",
    "some_app.formats",
]

Django が特定のフォーマットを検索する際、与えられた Python パス全体を通過し、実際にそのフォーマットを定義しているモジュールが見つかるまで探します。つまり、リストの上位にあるパッケージで定義されたフォーマットが、下位にある同じフォーマットより優先されます。

利用可能なフォーマットは以下の通りです:

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 を記述した、コンパイルされた正規表現オブジェクトのリストです（詳細は、エラーレポートの管理を参照）。正規表現は、 リクエストのフルパス (クエリ文字列を含む) と照合されます。 favicon.ico や robots.txt のような一般的なファイルを提供していない場合に使用してください。

これは、 BrokenLinkEmailsMiddleware が有効になっている場合にのみ使用されます（詳細は、ミドルウェア (Middleware) を参照）。

`INSTALLED_APPS`¶

デフォルト値: [] (空のリスト)

このDjangoインストールで有効になっているすべてのアプリケーションを示す文字列のリスト。各文字列は、Pythonのドット区切りパスである必要があります。

アプリケーションの設定クラス（推奨）、または
アプリケーションを含むパッケージ。

アプリケーション設定について詳しく知る。

アプリケーションレジストリを利用してインストロスペクションを行う

コードからは直接 INSTALLED_APPS にアクセスしないでください。代わりに django.apps.apps を使用してください。

アプリケーション名とラベルは、 INSTALLED_APPS 内で一意である必要があります。

アプリケーションの属性 names （アプリケーションパッケージへのドット区切りのPythonパス）はユニークである必要があります。同じアプリケーションを2度含める方法はなく、コードを別の名前で複製する以外にありません。

アプリケーション labels （デフォルトでは名前の最後の部分）も一意でなければなりません。例えば、 django.contrib.auth と myproject.auth を両方含めることはできません。しかし、異なる label を定義するカスタム設定でアプリケーションのラベルを変更することはできます。

これらのルールは、 INSTALLED_APPS がアプリケーション設定クラスを参照しているか、アプリケーションパッケージを参照しているかに関わらず適用されます。

いくつかのアプリケーションが同じリソース（テンプレート、静的ファイル、管理コマンド、翻訳）の異なるバージョンを提供する場合、 INSTALLED_APPS で最初にリストされたアプリケーションが優先されます。

`INTERNAL_IPS`¶

デフォルト値: [] (空のリスト)

文字列としての IP アドレスのリストで、以下の条件を満たします:

debug() コンテキストプロセッサを許可して、テンプレートコンテキストにいくつかの変数を追加します。
スタッフユーザーとしてログインしていなくても、 admindocsブックマークレットを使用できます。
AdminEmailHandler の電子メールで（"EXTERNAL" に対して）"internal" とマークされます。

`LANGUAGE_CODE`¶

デフォルト値: 'en-us'

このインストールに対する言語コードを表す文字列です。標準の言語 ID フォーマット内にある文字列を指定します。例えば、U.S. の英語は "en-us" です。list of language identifiers と国際化とローカライズも参照してください。

これは次の3つの目的を果たします。

ロケールミドルウェアが使用されていない場合、全ユーザにどの翻訳を提供するかを決めます。
ロケールミドルウェアがアクティブの場合、ユーザの好む言語が不明な場合やウェブサイトでサポートされていない場合に備えて、フォールバックの言語として利用されます。また、与えられた文字列に対して、ユーザの好む言語に対応する翻訳が存在しない場合にも、この設定が利用されます。
ローカライズが unlocalize フィルターや {% localize off %} タグで明示的に無効にされた場合、代わりにフォールバックのローカライズ形式が適用されます。詳細については、テンプレートでのローカライズの制御を参照してください。

詳しくは Django はどうやって言語の優先順位を検出するのか？を参照してください。

`LANGUAGES`¶

デフォルト値: 利用可能な全言語のリストです。このリストは常に拡大しており、ここにコピーを含めると速やかに時代遅れになってしまいます。現在の翻訳された言語のリストは、 django/conf/global_settings.py で確認できます。

リストは、(言語コード, 言語名) の形式の 2値タプルのリストです。例えば、('ja', 'Japanese') です。これは言語選択で利用可能な言語を指定します。詳細は国際化とローカライズを参照してください。

一般的には、デフォルト値で十分です。Django が提供する言語の部分集合に選択肢を限定したいときにのみ、この設定を自分でセットしてください。

カスタム LANGUAGES 設定を定義した場合、 gettext_lazy() 関数を使って言語名を翻訳文字列としてマークすることができます。

以下はサンプルの設定ファイルです:

from django.utils.translation import gettext_lazy as _

LANGUAGES = [
    ("de", _("German")),
    ("en", _("English")),
]

`LANGUAGES_BIDI`¶

デフォルト値: 右から左へ向かって書く言語のコード一覧です。これらの言語の現在の一覧は、 django/conf/global_settings.py を見ることで確認できます。

リストには、右から左へ書かれる言語の言語コードが含まれています。

基本的にはデフォルト値で十分です。Django が提供する言語のサブセットに言語選択を制限したい場合にのみ、この設定を設定してください。カスタムな LANGUAGES 設定を定義すると、双方向言語のリストに、特定サイトで有効になっていない言語コードが含まれる可能性があります。

`LOCALE_PATHS`¶

デフォルト値: [] (空のリスト)

Django が翻訳ファイルを探すディレクトリのリストです。Djangoはどうやって翻訳を見つけるのか？を参照してください。

実装例:

LOCALE_PATHS = [
    "/home/www/project/common_files/locale",
    "/var/local/translations/locale",
]

Django は、実際の翻訳ファイルを含む <locale_code>/LC_MESSAGES ディレクトリに対して、これらのパス内をそれぞれ見ていきます。

`LOGGING`¶

デフォルト値: ロギング設定のディレクトリ。

設定情報を含むデータ構造です。このデータ構造が空でない場合、その内容は LOGGING_CONFIG で説明されている設定メソッドへの引数として渡されます。

デフォルトのロギング設定では、 DEBUG が False の場合、HTTP 500 サーバーエラーをメールログハンドラーに送信します。詳細は、ロギングを設定するを参照してください。

デフォルトのログ設定は、 django/utils/log.py で確認できます。

`LOGGING_CONFIG`¶

デフォルト値: 'logging.config.dictConfig'

Django プロジェクトでロギングを設定するために使用される呼び出し可能オブジェクトへのパス。デフォルトでは Python の dictConfig 設定形式のインスタンスを指しています。

LOGGING_CONFIG を None に設定すると、ロギング設定プロセスはスキップされます。

`MANAGERS`¶

デフォルト値: [] (空のリスト)

ADMINS と同じ形式のリストで、 BrokenLinkEmailsMiddleware が有効な場合に、誰がリンク切れ通知を受け取るべきかを指定します。

`MEDIA_ROOT`¶

デフォルト値: '' (空文字列)

ユーザーがアップロードしたファイルを保存するディレクトリへの絶対ファイルシステムパス。

例: "/var/www/example.com/media/"

`MEDIA_URL`¶

デフォルト値: '' (空文字列)

MEDIA_ROOT から提供されるメディアを扱う URL は、保存されたファイルの管理に使用されます。空でない値に設定されている場合は、スラッシュで終わる必要があります。開発環境と本番環境の両方で、これらのファイルが配信されるように設定する必要があります。

テンプレートで {{ MEDIA_URL }} を使用したい場合は、 TEMPLATES の 'context_processors' オプションに 'django.template.context_processors.media' を追加してください。

例: "https://media.example.com/"

警告

信頼できないユーザーからコンテンツアップロードを許可する場合、セキュリティリスクが存在します！緩和策の詳細は、ユーザーがアップロードしたコンテンツのセキュリティガイドを参照してください。

警告

MEDIA_URL と STATIC_URL は異なる値を持つ必要があります。詳細については MEDIA_ROOT を参照してください。

注釈

もし MEDIA_URL が相対パスである場合、それは SCRIPT_NAME の値（設定されていない場合は / ）で接頭辞が付けられます。これにより、追加の設定を行わずにDjangoアプリケーションをサブパスで提供するのが簡単になります。

`MIDDLEWARE`¶

デフォルト値: None

使用するミドルウェアのリストです。ミドルウェア (Middleware) を参照してください。

`MIGRATION_MODULES`¶

デフォルト値: {} (空の辞書)

アプリごとにマイグレーションモジュールを検索できるパッケージを指定する辞書です。この設定のデフォルト値は空の辞書ですが、マイグレーションモジュールのデフォルトパッケージ名は migrations です。

実装例:

{"blog": "blog.db_migrations"}

この場合、blog アプリに関連するマイグレーションは blog.db_migrations パッケージに含まれます。

app_label 引数を提供した場合、makemigrations はパッケージがまだ存在しない場合、自動的にパッケージを作成します。

アプリに対して None を値として指定すると、Djangoはそのアプリをマイグレーションを持たないアプリとみなします。これは、例えば、テストの設定ファイルにおいてマイグレーションをスキップしながらテストを行うために使用できます (アプリのモデルのためにテーブルは依然として作成されます)。テスト中にすべてのアプリのマイグレーションを無効にするには、代わりに MIGRATE を False に設定できます。プロジェクトの一般的な設定で MIGRATION_MODULES を使用している場合、アプリのためにテーブルを作成したい場合は migrate --run-syncdb オプションを使用してください。

`MONTH_DAY_FORMAT`¶

デフォルト値: 'F j'

admin change-list のページの日付をフォーマットする時のデフォルト値です。システムの他の場所で月と日だけが表示される場合に使用される可能性があります。

たとえば、Django の admin change-list のページを日付でフィルタする時、与えられた日付のヘッダには月と日が表示されます。

対応するロケールによる書式が優先され、適用されることに留意してください。

使用可能な日付フォーマット文字列 を参照してください。また、DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT も参照してください。

`NUMBER_GROUPING`¶

デフォルト値: 0

数の整数部分をまとめるときの桁数です。

よくある使われ方は、1000倍の区切り文字を表示するときです。0 に設定すると、数に対してグルーピングを行いません。0 より大きい値を指定すると、 THOUSAND_SEPARATOR が区切り位置を求めるのに使います。

一部の地域では、数字の桁区切りが一様でないことがあります。たとえば、en_IN では 10,00,00,000 のようになります。この場合、適用するべき桁グループの数を示すシーケンスを提供できます。最初の数値は小数点区切り記号の前のグループのサイズを定義し、それに続く各数値は前のグループのサイズを定義します。シーケンスが -1 で終了すると、さらなるグループ分けは行われません。シーケンスが 0 で終了すると、最後のグループのサイズが残りの数値に適用されます。

en_IN のための例のタプル:

NUMBER_GROUPING = (3, 2, 0)

ロケールが指定する形式が優先され、それが適用されるので注意してください。

DECIMAL_SEPARATOR, THOUSAND_SEPARATOR, USE_THOUSAND_SEPARATOR も参照してください。

`PREPEND_WWW`¶

デフォルト値: False

"www." サブドメインが URL に含まれていない時、自動的に頭に追加するかどうかを指定します。この設定が有効になるのは、 CommonMiddleware がインストールされている時のみです (参照: ミドルウェア (Middleware))。APPEND_SLASH も参照してください。

`ROOT_URLCONF`¶

デフォルト値: 定義されていません

あなたのルートURLconfへの完全なPythonインポートパスを表す文字列です。例えば "mydjangoapps.urls" のようになります。受け取る HttpRequest オブジェクトの urlconf 属性を設定することで、リクエストごとにオーバーライドできます。詳細については Django のリクエスト処理を参照してください。

`SECRET_KEY`¶

デフォルト値: '' (空文字列)

Django のインストールごとに設定される個別の秘密鍵です。暗号署名に使われる鍵であり、ユニークかつ予測できない値でなければなりません。

django-admin startproject コマンドを実行すると、新しいプロジェクトを作成するたびに、ランダムに生成された SECRET_KEY を自動的に設定してくれます。

キーを使用する際、テキストまたはバイトであるとは仮定すべきではありません。使用する際は必ず、それを目的の型に変換するために、 force_str() または force_bytes() を通して行う必要があります。

SECRET_KEY が設定されていない場合、Django は起動しません。

警告

この値は、絶対に秘密にしてください。

Django を既知の SECRET_KEY で実行してしまうと、Django の多数のセキュリティプロテクションが破られ、結果的に、コンピュータの重要な権限が取得されてリモートコード実行の脆弱性に晒されてしまいます。

秘密鍵は次のような場合に使われます。

django.contrib.sessions.backends.cache 以外のセッションバックエンドを使用しているか、デフォルトの get_session_auth_hash() を使用している場合は、すべての sessions 。
CookieStorage または FallbackStorage を使用している場合、すべての messages 。
すべての PasswordResetView トークン。
異なるキーが指定されていない限り、すべての暗号署名の使用。

SECRET_KEY で設定されていない、または SECRET_KEY_FALLBACKS に含まれていない秘密鍵は、上記のすべてが無効になります。秘密鍵をローテーションさせるときは、古い鍵を一時的に SECRET_KEY_FALLBACKS に移動するべきです。秘密鍵は、ユーザーのパスワードには使用されず、鍵のローテーションがそれらに影響を与えることはありません。

注釈

django-admin startproject で作成されるデフォルトの settings.py ファイルは、利便性のため、ユニークな SECRET_KEY を生成します。

`SECRET_KEY_FALLBACKS`¶

デフォルト値: []

特定のDjangoインストールに関連するフォールバックの秘密鍵のリストです。これらは、 SECRET_KEY のローテーションを可能にするために使用されます。

秘密鍵をローテーションするために、新しい SECRET_KEY を設定し、以前の値を SECRET_KEY_FALLBACKS の最初に移動してください。その後、それらを使用するセッション、パスワードリセットトークンなどを期限切れにする準備ができたら、SECRET_KEY_FALLBACKS の最後から古い値を削除してください。

注釈

署名操作は計算コストが高いものです。 SECRET_KEY_FALLBACKS に複数の古いキー値を持つことは、以前のキーと一致しないすべてのチェックに追加のオーバーヘッドをもたらします。

そのため、適切な期間が経過した後には、フォールバック値を削除し、キーローテーションを行うべきです。

秘密キーの値の使用時は、それらがテキストまたはバイトであると仮定すべきではありません。使用する際には、希望のタイプに変換するために force_str() または force_bytes() を通じて行うべきです。

`SECURE_CONTENT_TYPE_NOSNIFF`¶

デフォルト値: True

True であれば、 SecurityMiddleware は、既にそれを持っていないすべてのレスポンスに X-Content-Type-Options: nosniff ヘッダーを設定します。

`SECURE_CROSS_ORIGIN_OPENER_POLICY`¶

デフォルト値: 'same-origin'

None に設定されていない限り、 SecurityMiddleware はそれが既に設定されていないすべてのレスポンスに、提供された値を使用して同一生成元ポリシー (Cross-Origin Opener Policy) ヘッダを設定します。

`SECURE_HSTS_INCLUDE_SUBDOMAINS`¶

デフォルト値: False

True の場合、 SecurityMiddleware は HTTP Strict Transport Security ヘッダーに includeSubDomains ディレクティブを追加します。 SECURE_HSTS_SECONDS が 0 でない値に設定されていない限り、効果はありません。

警告

これを誤って設定すると、 SECURE_HSTS_SECONDS の値に対して不可逆的にサイトを壊すことがあります。まず HTTP Strict Transport Security のドキュメントを読んでください。

`SECURE_HSTS_PRELOAD`¶

デフォルト値: False

True の場合、 SecurityMiddleware は preload 指令を HTTP Strict Transport Security ヘッダーに追加します。これは SECURE_HSTS_SECONDS が非ゼロの値に設定されていない限り、効果がありません。

`SECURE_HSTS_SECONDS`¶

デフォルト値: 0

ゼロでない整数値に設定されている場合、 SecurityMiddleware は、まだ設定されていないすべてのレスポンスに対して HTTP Strict Transport Security ヘッダを設定します。

警告

設定を誤ると、しばらくの間サイトが壊れてしまう可能性があります。まずは HTTP Strict Transport Security のドキュメントをお読みください。

`SECURE_PROXY_SSL_HEADER`¶

デフォルト値: 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つの要素を持つタプルを設定します。検索するヘッダーの名前と必要な値です。例えば:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

これは、次のような場合に、プロキシから来る X-Forwarded-Proto ヘッダーを Django が信頼し、リクエストが安全であること（つまり、元々は HTTPS を介して入ってきた）を保証するように指示します:

ヘッダーの値が 'https' であるか、または
その初期値、プロトコルのカンマ区切りリスト (例: 'https,http,http') の最も左の値が 'https' の場合。

この設定は、プロキシを制御している場合、またはこのヘッダーを適切に設定/削除するという他の保証がある場合にのみ設定すべきです。

ヘッダーは request.META で使われる形式にする必要があります。すべて大文字で、おそらく HTTP_ で始まります。(Django は、ヘッダー名の先頭に 'HTTP_' を自動的に追加してから、ヘッダーを request.META で利用可能にします。)

警告

この設定を変更すると、サイトのセキュリティが損なわれる可能性があります。変更する前に、設定を完全に理解してください。

次のすべてが真であることを設定する前に確認してください（上記の例からの値を想定しています）:

あなたの Django アプリがプロキシの背後にあること。
プロキシは、カンマ区切りのプロトコルリストが含まれている場合でも、すべての受信リクエストから X-Forwarded-Proto ヘッダーを削除すること。言い換えると、エンドユーザーがそのヘッダーをリクエストに含めた場合、プロキシはそれを破棄すること。
プロキシは X-Forwarded-Proto ヘッダを設定して Django に送ること、これは HTTPS 経由で元々来たリクエストに対してのみです。

これらのいずれかが真でない場合は、この設定を None に設定したままにして、カスタムミドルウェアを介して HTTPS を決定する別の方法を見つけるべきです。

`SECURE_REDIRECT_EXEMPT`¶

デフォルト値: [] (空のリスト)

このリスト内の正規表現にURLパスが一致する場合、リクエストはHTTPSへリダイレクトされません。 SecurityMiddleware はURLパスから先頭のスラッシュを削除するため、パターンにはそれを含めるべきではありません。例: SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …] 。SECURE_SSL_REDIRECT が False の場合、この設定は効果がありません。

`SECURE_REFERRER_POLICY`¶

デフォルト値: 'same-origin'

設定されていれば、 SecurityMiddleware は、それがまだ設定されていないすべてのレスポンスに対して、提供された値に従ってリファラ・ポリシーヘッダーを設定します。

`SECURE_SSL_HOST`¶

デフォルト値: None

文字列 (例: secure.example.com) を設定すると、すべてのSSLリダイレクトが元々リクエストされたホスト (例: www.example.com) の代わりにこのホストに向けられます。 SECURE_SSL_REDIRECT が False の場合、この設定は無効です。

`SECURE_SSL_REDIRECT`¶

デフォルト値: False

もし True なら、 SecurityMiddleware は、全てのHTTPSではないリクエストをHTTPSにリダイレクトします (SECURE_REDIRECT_EXEMPT でリストされた正規表現に一致するURLを除く)。

注釈

True に変更するとリダイレクトが無限に発生する場合、おそらくサイトがプロキシの後ろで実行されており、どのリクエストがセキュアかを判断できていないことを意味しています。おそらくプロキシはセキュアなリクエストを示すヘッダを設定しています。この問題を修正するには、そのヘッダが何かを調べ、 SECURE_PROXY_SSL_HEADER 設定を適切に設定してください。

`SERIALIZATION_MODULES`¶

デフォルト値: 定義されていません

シリアライゼーションタイプに対する文字列識別子をキーとし、シリアライザ定義 (文字列として提供される) を含むモジュールのディクショナリです。例えば、YAML シリアライザを定義するには、以下を使用します。

SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}

`SERVER_EMAIL`¶

デフォルト値: 'root@localhost'

エラーメッセージが送信されるメールアドレスは、 ADMINS や MANAGERS に送信されるメールの送信元となるアドレスです。このアドレスは、選択したメール送信プロトコルで有効な任意の形式を取ることができます。

私のメールが異なるアドレスから送信されるのはなぜですか？

このアドレスはエラーメッセージ専用です。普通のメールメッセージが send_mail() で送信される際のアドレスとは 異なります 。そのためには、 DEFAULT_FROM_EMAIL を参照してください。

`SHORT_DATE_FORMAT`¶

デフォルト値: 'm/d/Y' (例: 12/31/2003)

テンプレートで日付フィールドを表示するために利用できるフォーマットです。但し、対応するロケールによって指定されたフォーマットが優先され、代わりに適用されます。詳細は、 使用可能な日付フォーマット文字列 を参照してください。

関連項目: DATE_FORMAT, SHORT_DATETIME_FORMAT

`SHORT_DATETIME_FORMAT`¶

デフォルト値: 'm/d/Y P' (例: 12/31/2003 4 p.m.)

テンプレートで日時フィールドを表示するために使用できる利用可能なフォーマットです。対応するロケールに従ったフォーマットが優先され、代わりに適用されます。詳細は、 利用可能な文字列フォーマット をご覧ください。

関連項目: DATE_FORMAT, SHORT_DATE_FORMAT

`SIGNING_BACKEND`¶

デフォルト値: 'django.core.signing.TimestampSigner'

クッキーやその他のデータに署名する際に使用されるバックエンド。

関連項目: 暗号署名ドキュメント

`SILENCED_SYSTEM_CHECKS`¶

デフォルト値: [] (空のリスト)

システムチェックフレームワークによって生成されたメッセージの識別子リスト (例: ["models.W001"]) で、永久に認識し、無視したいものです。無視されたチェックはコンソールに出力されません。

関連項目: システムチェックフレームワークドキュメント

`STORAGES`¶

デフォルト値:

{
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",
    },
}

Djangoで使用されるすべてのストレージの設定を含む辞書です。ストレージエイリアスを個々のストレージのオプションを含む辞書にマッピングした入れ子構造の辞書です。

ストレージには任意のエイリアスを指定できます。ただし、特別な意味を持つ2つのエイリアスがあります。

default はファイルを管理するためのものです。 'django.core.files.storage.FileSystemStorage' がデフォルトのストレージエンジンです。
staticfiles は静的ファイルの管理用です。 'django.contrib.staticfiles.storage.StaticFilesStorage' がデフォルトのストレージエンジンです。

以下は、カスタムファイルストレージ example を定義する settings.py のコードの例です。

STORAGES = {
    # ...
    "example": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
        "OPTIONS": {
            "location": "/example",
            "base_url": "/example/",
        },
    },
}

**kwargs を使って、 BACKEND の初期化時に OPTIONS が渡されます。

使用可能なストレージバックエンドのインスタンスは、 django.core.files.storage.storages から取得できます。 STORAGES でのバックエンド定義に対応するキーを使用してください。

私の値はデフォルト値とマージされますか？

この設定を定義すると、デフォルト値を上書きし、それとは 結合されません 。

`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'

Django に付属していないテンプレートバックエンドを使用するには、BACKEND を完全修飾パス (例： 'mypackage.whatever.Backend') で設定します。

`NAME`¶

デフォルト値: 下記を参照してください

この特定のテンプレートエンジンのエイリアス。エンジンを選択するための識別子です。エイリアスは、構成されたすべてのテンプレートエンジンで一意である必要があります。

エンジンクラスを定義するモジュールの名前がデフォルト値です。つまり、指定されていない場合 BACKEND の最後から2番目の要素になります。例えば、バックエンドが 'mypackage.whatever.Backend' であれば、そのデフォルト名は 'whatever' になります。

`DIRS`¶

デフォルト値: [] (空のリスト)

エンジンがテンプレートのソースファイルを探すべきディレクトリ、検索順序付き。

`APP_DIRS`¶

デフォルト値: False

エンジンがインストールされたアプリケーション内でテンプレートのソースファイルを探すべきかどうか。

注釈

django-admin startproject によって生成されるデフォルトの settings.py ファイルは 'APP_DIRS': True を設定します。

`OPTIONS`¶

デフォルト値: {} (空のディクショナリ)

テンプレートバックエンドに渡す追加のパラメーターです。利用可能なパラメーターは、テンプレートバックエンドによって異なります。組み込みバックエンドのオプションについては、 DjangoTemplates と Jinja2 を参照してください。

`TEST_RUNNER`¶

デフォルト値: 'django.test.runner.DiscoverRunner'

テストスイートを開始するために使用するクラスの名前。ほかのテストフレームワークを使うを参照してください。

`TEST_NON_SERIALIZED_APPS`¶

デフォルト値: [] (空のリスト)

TransactionTestCase やトランザクションを使用しないデータベースバックエンドのテスト間でデータベースの状態を復元するために、Djangoはテスト実行が開始されるとすべてのアプリの内容をシリアライズし、それを必要とするテストを実行する前にそのコピーからリロードできるようにします。

これによって、テストランナーの起動時間が遅くなります。この機能が不要なアプリがある場合は、完全な名前をここに追加して、このシリアライズ処理から除外できます (例: 'django.contrib.contenttypes')。

`THOUSAND_SEPARATOR`¶

デフォルト値: ',' (カンマ)

数字のフォーマット時に使用するデフォルトの千の区切り記号です。この設定は、USE_THOUSAND_SEPARATOR が True であり、NUMBER_GROUPING が 0 より大きい場合にのみ使用されます。

ロケールが指定する形式が優先され、それが適用されるので注意してください。

`TIME_FORMAT`¶

デフォルト値: 'P' (例: 4 p.m.)

システムのどの部分でも、時間フィールドを表示する際に使用するデフォルトの書式設定です。ロケールに依存する書式が優先され、代わりに適用されます。 使用可能な日付フォーマット文字列 を参照してください。

関連項目: 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 テンプレートフィルタからの形式文字列ではなく、Pythonの datetime モジュールの構文を使用していることに注意してください。

ロケールが指定するフォーマットが優先され、代わりに適用されます。

関連項目: DATE_INPUT_FORMATS および DATETIME_INPUT_FORMATS を参照してください。

`TIME_ZONE`¶

デフォルト値: 'America/Chicago'

このインストールのタイムゾーンを表す文字列です。タイムゾーンの一覧は、 list of time zones を参照してください。

注釈

Django は最初 TIME_ZONE を 'America/Chicago' にしてリリースされていたので、後方互換性のために (プロジェクト内で settings.py が定義されていないときに使われる) グローバル設定は 'America/Chicago' のままになっています。新しいプロジェクトのテンプレートではデフォルトは 'UTC' です。

これは必ずしもサーバのタイムゾーンではないことに注意してください。たとえば、1 つのサーバ内に Django 製のサイトがあり、それぞれが異なるタイムゾーン設定を持つこともできます。

USE_TZ が False のとき、これは Django が日時を保持するタイムゾーンとなります。USE_TZ が True のとき、これは Django がテンプレート内で日時を表示するため、およびフォーム内で入力された日時を解釈するために使う、デフォルトのタイムゾーンです。

Unix 環境 (ここで time.tzset() が実装されている場合)では、Djangoは os.environ['TZ'] 変数を TIME_ZONE 設定で指定したタイムゾーンに設定します。したがって、すべてのビューとモデルは自動的にこのタイムゾーンで動作します。しかし、手動で設定を行うで説明されているような手動設定オプションを使用している場合は、Djangoは TZ 環境変数を設定しません。Djangoが TZ 環境変数を設定しない場合は、プロセスが正しい環境で実行されていることを確認するのはあなたの責任です。

注釈

Django は、Windows 環境で代替タイムゾーンを正しく扱うことができません。Django を Windows で実行している場合、TIME_ZONE はシステムのタイムゾーンに合わせてセットする必要があります。

`USE_I18N`¶

デフォルト値: True

Djangoの翻訳システムを有効にするかどうかを指定する真偽値です。パフォーマンスのためにオフにする方法を提供します。これが False に設定されている場合、Djangoは翻訳システムを読み込まないように一部の最適化を行います。

`WSGI_APPLICATION`¶

デフォルト値: None

Djangoの組み込みサーバー (例えば runserver) が使用するWSGIアプリケーションオブジェクトの完全なPythonパスです。django-admin startproject 管理コマンドは標準の wsgi.py ファイルを作成し、その中に application 呼び出し可能オブジェクトを含め、この設定をその application にポイントします。

設定されていない場合は、 django.core.wsgi.get_wsgi_application() の返り値が使用されます。この場合、runserver の動作は以前のDjangoバージョンと同一になります。

`YEAR_MONTH_FORMAT`¶

デフォルト値: 'F Y'

Django管理サイトのチェンジリストページで、年と月のみが表示される場合に、デフォルトの日付フィールドの書式設定を使用する方法。そして、システムの他の部分でも同様に適用される可能性があります。

たとえば、Djangoの管理画面のチェンジリストページが日付で絞り込まれている場合、指定された月のヘッダーには月と年が表示されます。異なるロケールには異なる形式があります。例えば、米国英語では「January 2006」と表示されますが、別のロケールでは「2006/January」のように表示されるかもしれません。

対応するロケールによる書式が優先され、適用されることに留意してください。

許可される日付フォーマット文字列については、 使用可能な日付フォーマット文字列 を参照してください。また、 DATE_FORMAT 、 DATETIME_FORMAT 、 TIME_FORMAT および MONTH_DAY_FORMAT も参照してください。

`X_FRAME_OPTIONS`¶

デフォルト値: 'DENY'

XFrameOptionsMiddleware によって使用される X-Frame-Options ヘッダのデフォルト値については、クリックジャッキング保護のドキュメントを参照してください。

認証 ¶

django.contrib.auth の設定

`AUTHENTICATION_BACKENDS`¶

デフォルト値: ['django.contrib.auth.backends.ModelBackend']

ユーザーを認証しようとするときに使用する認証バックエンドクラスのリスト（文字列形式）。詳細については認証バックエンドのドキュメントを参照してください。

`AUTH_USER_MODEL`¶

デフォルト値: 'auth.User'

User を表すために使うモデルです。カスタムの User モデルを置き換えるを参照してください。

警告

プロジェクトのライフサイクル中 (つまり、それに依存するモデルを作成しマイグレーションした後 )に AUTH_USER_MODEL 設定を変更することは困難です。プロジェクト開始時に設定し、参照するモデルは、それが存在するアプリの最初のマイグレーションで利用可能である必要があります。詳細は、カスタムの User モデルを置き換えるを参照してください。

`LOGIN_URL`¶

デフォルト値: '/accounts/login/'

login_required() デコレータ、LoginRequiredMixin、AccessMixin を使っているとき、または LoginRequiredMiddleware ミドルウェアがインストールされている場合に、ログインのためにリダイレクトされる URL または名前付き URL パターンです。

`LOGOUT_REDIRECT_URL`¶

デフォルト値: None

リクエストがログアウト後にリダイレクトされるURLまたは名前付きURLパターンで、 LogoutView が next_page 属性を持っていない場合に使用されます。

None の場合、リダイレクトは行われず、ログアウトビューがレンダリングされます。

`PASSWORD_RESET_TIMEOUT`¶

デフォルト値: 259200 (秒単位で、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",
    "django.contrib.auth.hashers.ScryptPasswordHasher",
]

`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'

詳細については、メッセージストレージバックエンドを参照してください。

Cookieを使用するバックエンド -- 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_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

ユーザーがブラウザを閉じたときにセッションを終了させるかどうか。ブラウザ起動中のみ有効なセッション vs. 永続的なセッションを参照してください。

`SESSION_FILE_PATH`¶

デフォルト値: None

ファイルベースのセッションストレージを使用している場合、この設定は Django がセッションデータを格納するディレクトリを設定します。デフォルト値 (None) が使用される場合、Django はシステムの標準的な一時ディレクトリを使用します。

`SESSION_SAVE_EVERY_REQUEST`¶

デフォルト値: False

すべてのリクエストにおいてセッションデータを保存するかどうか。これが False (デフォルト) の場合、セッションデータは変更された場合にのみ保存されます。つまり、その辞書の値に何らかの代入や削除が行われた場合です。この設定が有効であっても、空のセッションは作成されません。

`SESSION_SERIALIZER`¶

デフォルト値: 'django.contrib.sessions.serializers.JSONSerializer'

セッションデータのシリアライズに使用するシリアライザクラスの完全なインポートパスです。含まれているシリアライザは次のとおりです:

'django.contrib.sessions.serializers.JSONSerializer'

詳細については、セッションのシリアライズを参照してください。

サイト ¶

django.contrib.sites の設定。

`SITE_ID`¶

デフォルト値: 定義されていません

django_site データベーステーブルの現在のサイトの ID（整数）です。これを使用することで、アプリケーションデータが特定のサイトにフックでき、単一のデータベースで複数のサイトのコンテンツを管理できます。

静的ファイル ¶

django.contrib.staticfiles の設定。

`STATIC_ROOT`¶

デフォルト値: None

collectstatic がデプロイメント用に静的ファイルを収集するディレクトリの絶対パスです。

例: "/var/www/example.com/static/"

staticfiles contrib アプリが有効になっている場合（デフォルトのプロジェクトテンプレートにあるように）、 collectstatic 管理コマンドは静的ファイルをこのディレクトリに収集します。使用法についての詳細は、静的ファイルの管理のHow-toをご覧ください。

警告

これは、永続的な場所から静的ファイルを一つのディレクトリに集めて、デプロイを容易にするための最初は空の宛先ディレクトリであることに注意してください。これは、静的ファイルを永続的に保存する場所 ではありません 。静的ファイルを永続的に保存するためには、 staticfiles の finders によって見つかるディレクトリ（デフォルトでは、'static/' アプリサブディレクトリと、STATICFILES_DIRS で含めた任意のディレクトリ）に保存してください。

`STATIC_URL`¶

デフォルト値: None

STATIC_ROOT に位置する静的ファイルを参照する際に使用する URL。

例: "static/" または "https://static.example.com/"

None でない場合、これはアセット定義 (Media クラス) および staticfiles アプリにおいて基本パスとして使用されます。

空でない値に設定されている場合、スラッシュで終わらなければなりません。

これらのファイルを開発環境で提供するためには設定が必要になるかもしれませんし、本番環境では間違いなくそうする必要があります本番環境。

注釈

STATIC_URL が相対パスの場合、サーバーが提供する SCRIPT_NAME の値（設定されていない場合は /）によってプレフィックスが付けられます。これにより、追加の設定を settings に追加することなく、Django アプリケーションをサブパスで提供することが簡単になります。

`STATICFILES_DIRS`¶

デフォルト値: [] (空のリスト)

この設定は FileSystemFinder のファインダーが有効になっている場合に staticfiles アプリが通過する追加の場所を定義します。たとえば、collectstatic や findstatic 管理コマンドを使用している場合や、静的ファイル提供ビューを使用している場合などです。

これは、追加のファイルディレクトリへのフルパスを含む文字列のリストに設定する必要があります。例:

STATICFILES_DIRS = [
    "/home/special.polls.com/polls/static",
    "/home/polls.com/polls/static",
    "/opt/webfiles/common",
]

これらのパスは、WindowsでもUnixスタイルのスラッシュを使用する必要があることに注意してください（例： "C:/Users/user/mysite/extra_static_content" ）。

プレフィックス(オプション)¶

追加の名前空間である場所の一つを参照したい場合、 オプションで (prefix, path) の形のタプルとしてプレフィックスを提供できます。例えば:

STATICFILES_DIRS = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]

たとえば、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' %}">

`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 を使用して）を見つけます。同じ名前のファイルが複数存在する場合、最初に見つかったファイルが使用されます。

デフォルトで無効になっているファインダーが 1 つあります: django.contrib.staticfiles.finders.DefaultStorageFinder 。これを STATICFILES_FINDERS 設定に追加すると、 STORAGES 設定の default キーで定義されたデフォルトファイルストレージ内の静的ファイルを探します。

注釈

AppDirectoriesFinder ファインダーを使用する場合、サイトの INSTALLED_APPS 設定にアプリを追加して、staticfiles によってアプリが見つけられるようにしてください。

静的ファイルファインダーは現在、プライベートインターフェースとみなされており、このインターフェースはドキュメント化されていません。

コア設定トピック別インデックス ¶

グローバル化 (`i18n`/`l10n`)¶

ローカライズ (`l10n`)¶

DATE_FORMAT
DATE_INPUT_FORMATS
DATETIME_FORMAT
DATETIME_INPUT_FORMATS
DECIMAL_SEPARATOR
LANGUAGE_CODE
MONTH_DAY_FORMAT
NUMBER_GROUPING
SHORT_DATE_FORMAT
SHORT_DATETIME_FORMAT
THOUSAND_SEPARATOR
TIME_FORMAT
TIME_INPUT_FORMATS
USE_THOUSAND_SEPARATOR
YEAR_MONTH_FORMAT

ロギング¶

LOGGING
LOGGING_CONFIG

モデル¶

ABSOLUTE_URL_OVERRIDES
FIXTURE_DIRS
INSTALLED_APPS

セキュリティ¶

クロスサイトリクエストフォージェリ (CSRF) 保護
SECRET_KEY
SECRET_KEY_FALLBACKS
X_FRAME_OPTIONS

シリアライズ¶

DEFAULT_CHARSET
SERIALIZATION_MODULES

テンプレート¶

TEMPLATES

テスト¶

データベース: テスト
TEST_NON_SERIALIZED_APPS
TEST_RUNNER

URL¶

APPEND_SLASH
PREPEND_WWW
ROOT_URLCONF

SchemaEditor

シグナル

ドキュメント

設定¶

コアの設定¶

ABSOLUTE_URL_OVERRIDES¶

ADMINS¶

ALLOWED_HOSTS¶

APPEND_SLASH¶

CACHES¶

BACKEND¶

KEY_FUNCTION¶

KEY_PREFIX¶

LOCATION¶

OPTIONS¶

TIMEOUT¶

VERSION¶

CACHE_MIDDLEWARE_ALIAS¶

CACHE_MIDDLEWARE_KEY_PREFIX¶

CACHE_MIDDLEWARE_SECONDS¶

CSRF_COOKIE_AGE¶

CSRF_COOKIE_DOMAIN¶

CSRF_COOKIE_HTTPONLY¶

CSRF_COOKIE_NAME¶

CSRF_COOKIE_PATH¶

CSRF_COOKIE_SAMESITE¶

CSRF_COOKIE_SECURE¶

CSRF_USE_SESSIONS¶

CSRF_FAILURE_VIEW¶

CSRF_HEADER_NAME¶

CSRF_TRUSTED_ORIGINS¶

DATABASES¶

ATOMIC_REQUESTS¶

AUTOCOMMIT¶

ENGINE¶

HOST¶

NAME¶

CONN_MAX_AGE¶

CONN_HEALTH_CHECKS¶

OPTIONS¶

PASSWORD¶

PORT¶

TIME_ZONE¶

DISABLE_SERVER_SIDE_CURSORS¶

USER¶

TEST¶

CHARSET¶

COLLATION¶

DEPENDENCIES¶

MIGRATE¶

MIRROR¶

NAME¶

TEMPLATE¶

CREATE_DB¶

CREATE_USER¶

USER¶

PASSWORD¶

ORACLE_MANAGED_FILES¶

TBLSPACE¶

TBLSPACE_TMP¶

DATAFILE¶

DATAFILE_TMP¶

DATAFILE_MAXSIZE¶

DATAFILE_TMP_MAXSIZE¶

DATAFILE_SIZE¶

DATAFILE_TMP_SIZE¶

DATAFILE_EXTSIZE¶

DATAFILE_TMP_EXTSIZE¶

DATA_UPLOAD_MAX_MEMORY_SIZE¶

DATA_UPLOAD_MAX_NUMBER_FIELDS¶

DATA_UPLOAD_MAX_NUMBER_FILES¶

DATABASE_ROUTERS¶

DATE_FORMAT¶

DATE_INPUT_FORMATS¶

DATETIME_FORMAT¶

DATETIME_INPUT_FORMATS¶

DEBUG¶

DEBUG_PROPAGATE_EXCEPTIONS¶

DECIMAL_SEPARATOR¶

DEFAULT_AUTO_FIELD¶

DEFAULT_CHARSET¶

DEFAULT_EXCEPTION_REPORTER¶

コアの設定 ¶

`ABSOLUTE_URL_OVERRIDES`¶

`ADMINS`¶

`ALLOWED_HOSTS`¶

`APPEND_SLASH`¶

`CACHES`¶

`BACKEND`¶

`KEY_FUNCTION`¶

`KEY_PREFIX`¶

`LOCATION`¶

`OPTIONS`¶

`TIMEOUT`¶

`VERSION`¶

`CACHE_MIDDLEWARE_ALIAS`¶

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

`CACHE_MIDDLEWARE_SECONDS`¶

`CSRF_COOKIE_AGE`¶

`CSRF_COOKIE_DOMAIN`¶

`CSRF_COOKIE_HTTPONLY`¶

`CSRF_COOKIE_NAME`¶

`CSRF_COOKIE_PATH`¶

`CSRF_COOKIE_SAMESITE`¶

`CSRF_COOKIE_SECURE`¶

`CSRF_USE_SESSIONS`¶

`CSRF_FAILURE_VIEW`¶

`CSRF_HEADER_NAME`¶

`CSRF_TRUSTED_ORIGINS`¶

`DATABASES`¶

`ATOMIC_REQUESTS`¶

`AUTOCOMMIT`¶

`ENGINE`¶

`HOST`¶

`NAME`¶

`CONN_MAX_AGE`¶

`CONN_HEALTH_CHECKS`¶

`OPTIONS`¶

`PASSWORD`¶

`PORT`¶

`TIME_ZONE`¶

`DISABLE_SERVER_SIDE_CURSORS`¶

`USER`¶

`TEST`¶

`CHARSET`¶

`COLLATION`¶

`DEPENDENCIES`¶

`MIGRATE`¶

`MIRROR`¶

`NAME`¶

`TEMPLATE`¶

`CREATE_DB`¶

`CREATE_USER`¶

`USER`¶

`PASSWORD`¶

`ORACLE_MANAGED_FILES`¶

`TBLSPACE`¶

`TBLSPACE_TMP`¶

`DATAFILE`¶

`DATAFILE_TMP`¶

`DATAFILE_MAXSIZE`¶

`DATAFILE_TMP_MAXSIZE`¶

`DATAFILE_SIZE`¶

`DATAFILE_TMP_SIZE`¶

`DATAFILE_EXTSIZE`¶

`DATAFILE_TMP_EXTSIZE`¶

`DATA_UPLOAD_MAX_MEMORY_SIZE`¶

`DATA_UPLOAD_MAX_NUMBER_FIELDS`¶

`DATA_UPLOAD_MAX_NUMBER_FILES`¶

`DATABASE_ROUTERS`¶

`DATE_FORMAT`¶

`DATE_INPUT_FORMATS`¶

`DATETIME_FORMAT`¶

`DATETIME_INPUT_FORMATS`¶

`DEBUG`¶

`DEBUG_PROPAGATE_EXCEPTIONS`¶

`DECIMAL_SEPARATOR`¶

`DEFAULT_AUTO_FIELD`¶

`DEFAULT_CHARSET`¶

`DEFAULT_EXCEPTION_REPORTER`¶

`DEFAULT_EXCEPTION_REPORTER_FILTER`¶

`DEFAULT_FROM_EMAIL`¶