設定

警告

設定を上書きするとき、特にデフォルト値が空でないリストや辞書の場合、例えば 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 が設定され、 AdminEmailHandlerLOGGING に設定されている場合(デフォルトで設定されています)、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.comwww.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 例外を起こします。

DEBUGTrue であり、かつ 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 など)を引き起こす可能性があるミドルウェアよりも前に、 SessionMiddlewareMIDDLEWARE に登録されている必要があります。 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.confunix_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_TZFalse の場合、このオプションを設定するとはエラーになります。

  • データベースバックエンドがタイムゾーンをサポートしていない場合(例えば 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_MODULESNone を値として設定するのと似ていますが、すべてのアプリに適用されます。

MIRROR

デフォルト値: None

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

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

NAME

デフォルト値: None

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

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

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

TEMPLATE

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

テストデータベースを作成するための template の名前 (例: 'template0')。

CREATE_DB

デフォルト値: True

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

False に設定されている場合、テストテーブルスペースはテストの開始時に自動的に作成されることも終了時に削除されることもありません。

CREATE_USER

デフォルト値: True

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

False に設定されている場合、テストの開始時にテストユーザーは自動的に作成されず、終了時に削除されません。

USER

デフォルト値: None

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

テストを実行する際に、Oracle データベースに接続するために使用するユーザー名です。指定しない場合、Django は 'test_' + USER を使用します。

PASSWORD

デフォルト値: None

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

テスト実行時に Oracle データベースに接続するために使用するパスワードです。指定しない場合、Django はランダムなパスワードを生成します。

ORACLE_MANAGED_FILES

デフォルト値: False

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

True に設定された場合、Oracle Managed Files (OMF) テーブル空間が使用されます。 DATAFILEDATAFILE_TMP は無視されます。

TBLSPACE

デフォルト値: None

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

テスト実行時に使用されるテーブル空間の名前。省略した場合、Django は 'test_' + USER を使用します。

TBLSPACE_TMP

デフォルト値: None

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

テスト実行時に使用される一時テーブルスペースの名前。指定しない場合、Djangoは 'test_' + USER + '_temp' を使用します。

DATAFILE

デフォルト値: None

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

使用する TBLSPACE のデータファイル名です。指定されない場合、Django は TBLSPACE + '.dbf' を使用します。

DATAFILE_TMP

デフォルト値: None

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

使用する TBLSPACE_TMP のデータファイルの名前です。指定されていない場合、Django は TBLSPACE_TMP + '.dbf' を使用します。

DATAFILE_MAXSIZE

デフォルト値: '500M'

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

DATAFILE が許容される最大サイズ。

DATAFILE_TMP_MAXSIZE

デフォルト値: '500M'

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

DATAFILE_TMP が拡大することが許可されている最大サイズ。

DATAFILE_SIZE

デフォルト値: '50M'

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

DATAFILE の初期サイズ。

DATAFILE_TMP_SIZE

デフォルト値: '50M'

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

DATAFILE_TMP の初期サイズ。

DATAFILE_EXTSIZE

デフォルト値: '25M'

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

DATAFILE がより多くのスペースを必要としたときに拡張される量。

DATAFILE_TMP_EXTSIZE

デフォルト値: '25M'

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

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

DATA_UPLOAD_MAX_MEMORY_SIZE

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

リクエストボディの最大サイズ (バイト単位) で、このサイズを超えると SuspiciousOperation (RequestDataTooBig) が発生します。このチェックは request.bodyrequest.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

New in Django 3.2.18.

デフォルト値: 100

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

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

DATABASE_ROUTERS

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

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

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

DATE_FORMAT

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

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

関連項目: DATETIME_FORMAT, TIME_FORMAT, SHORT_DATE_FORMAT

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_INPUT_FORMATS TIME_INPUT_FORMATS

DATETIME_FORMAT

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

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

関連項目 DATE_FORMAT, TIME_FORMAT, SHORT_DATETIME_FORMAT

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 をオンにした状態でサイトを本番環境にデプロイしないでください。

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

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

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

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

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

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

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

注釈

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

DEBUG_PROPAGATE_EXCEPTIONS

デフォルト値: False

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

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

DECIMAL_SEPARATOR

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

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

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

関連項目: NUMBER_GROUPING, THOUSAND_SEPARATOR, USE_THOUSAND_SEPARATOR

DEFAULT_AUTO_FIELD

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

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

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

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

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

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

これを解決するには、必要な ALTER TABLE ステップを実行するために、マイグレーションに RunSQL 操作を追加する必要があります。既存のテーブル名は、sqlmigratedbshell、またはフィールドの 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_FILE_STORAGE

デフォルト値: 'django.core.files.storage.FileSystemStorage'

特定のストレージシステムを指定しないファイル関連の操作に使用されるデフォルトファイルストレージクラス。詳細については、ファイルの管理 を参照してください。

バージョン 4.2 で非推奨: この設定は非推奨です。Django 4.2 以降、デフォルトのファイルストレージエンジンは STORAGES 設定の default キーを使用して設定できます。

DEFAULT_FROM_EMAIL

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

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

これは ADMINSMANAGERS へ送信されるエラーメッセージには影響しません。それについては 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_HOST 内で定義された SMTP サーバで使われるユーザ名です。空の場合、Django は認証を試みません。

EMAIL_HOST_PASSWORD も参照してください。

EMAIL_PORT

デフォルト値: 25

EMAIL_HOST 内で定義された SMTP サーバで使われるポート番号です。

EMAIL_SUBJECT_PREFIX

デフォルト値: '[Django] '

django.core.mail.mail_adminsdjango.core.mail.mail_managers で送信される E メールメッセージ用の表題行のプレフィックスです。最後の文字はスペースにするのが良いでしょう。

EMAIL_USE_LOCALTIME

デフォルト値: False

電子メールメッセージのSMTPの "Date" ヘッダーをローカルタイムゾーンで送信する (True) かUTCで送信する (False) か。

EMAIL_USE_TLS

デフォルト値: False

SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。明示的な TLS 接続に使われ、通常はポート 587 で行われます。接続がハングしてしまう場合は、暗黙的な TLS を示す EMAIL_USE_SSL を確認してみてください。

EMAIL_USE_SSL

デフォルト値: False

SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。ほとんどの E メールのドキュメントでは、この TLS 接続のタイプは SSL として参照されます。通常はポート 465 が使われます。接続がハングしてしまう場合は、暗黙的な TLS を示す EMAIL_USE_TLS を確認してみてください。

EMAIL_USE_TLS/EMAIL_USE_SSL は相互に排他的であることに注意してください。したがって、どちらか一方だけを True にセットしてください。

EMAIL_SSL_CERTFILE

デフォルト値: None

EMAIL_USE_SSL ないし EMAIL_USE_TLSTrue の場合、オプションで、SSL 接続用に使う PEM フォーマットの証明書チェーンファイルを指定できます。

EMAIL_SSL_KEYFILE

デフォルト値: None

EMAIL_USE_SSL ないし EMAIL_USE_TLSTrue の場合、オプションで、SSL 接続用に使う PEM フォーマットのプライベートキーファイルを指定できます。

EMAIL_SSL_CERTFILEEMAIL_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 の値を上書きするために使用できます。これは、好ましい値の書き換えられたバージョンまたはまったく提供されていない場合があります。また、django.setup() によって、リクエスト/レスポンスのサイクル外 (例: 管理コマンドやスタンドアローン スクリプト) で URL リゾルバスクリプトのプレフィックスを設定するために使用されます。これにより、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 表記を使用した名前であることが期待されます。たとえば、dept_BRen_US などです。

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

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

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

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

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

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

IGNORABLE_404_URLS

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

HTTP 404 エラーをメールで報告する際に無視すべき URL を記述した、コンパイルされた正規表現オブジェクトのリストです(詳細は、エラーレポートの管理 を参照)。正規表現は、 リクエストのフルパス (クエリ文字列を含む) と照合されます。 favicon.icorobots.txt のような一般的なファイルを提供していない場合に使用してください。

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

INSTALLED_APPS

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

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

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

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

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

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

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

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

アプリケーション labels (デフォルトでは名前の最後の部分) も一意でなければなりません。例えば、 django.contrib.authmyproject.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国際化とローカライズ も参照してください。

この設定が効果を持つためには、USE_I18N をアクティブにする必要があります。

これは 2 つの目的に使われます:

  • ロケールミドルウェアが使用されていない場合、全ユーザにどの翻訳を提供するかを決めます。
  • ロケールミドルウェアがアクティブの場合、ユーザの好む言語が不明な場合やウェブサイトでサポートされていない場合に備えて、フォールバックの言語として利用されます。また、与えられた文字列に対して、ユーザの好む言語に対応する翻訳が存在しない場合にも、この設定が利用されます。

詳しくは 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 で説明されている設定メソッドへの引数として渡されます。

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

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

LOGGING_CONFIG

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

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

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

MANAGERS

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

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

MEDIA_ROOT

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

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

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

関連項目: MEDIA_URL

警告

MEDIA_ROOTSTATIC_ROOT は異なる値である必要があります。STATIC_ROOT が導入される前は、静的ファイルを提供するために MEDIA_ROOT に依存したりフォールバックしたりすることが一般的でしたが、これは重大なセキュリティ上の影響を与える可能性があるので、これを防ぐための検証チェックが行われています。

MEDIA_URL

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

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

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

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

警告

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

警告

MEDIA_URLSTATIC_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はそのアプリをマイグレーションを持たないアプリとみなします。これは、例えば、テストの設定ファイルにおいてマイグレーションをスキップしながらテストを行うために使用できます (アプリのモデルのためにテーブルは依然として作成されます)。テスト中にすべてのアプリのマイグレーションを無効にするには、代わりに MIGRATEFalse に設定できます。プロジェクトの一般的な設定で 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 の多数のセキュリティプロテクションが破られ、結果的に、コンピュータの重要な権限が取得されてリモートコード実行の脆弱性に晒されてしまいます。

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

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 の場合、 SecurityMiddlewareHTTP Strict Transport Security ヘッダーに includeSubDomains ディレクティブを追加します。 SECURE_HSTS_SECONDS が 0 でない値に設定されていない限り、効果はありません。

警告

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

SECURE_HSTS_PRELOAD

デフォルト値: False

True の場合、 SecurityMiddlewarepreload 指令を 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_REDIRECTFalse の場合、この設定は効果がありません。

SECURE_REFERRER_POLICY

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

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

SECURE_SSL_HOST

デフォルト値: None

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

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'

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

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

このアドレスはエラーメッセージ専用です。普通のメールメッセージが 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

New in Django 4.2.

デフォルト値:

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

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

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

以下は、カスタムファイルストレージ 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

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

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

TEST_RUNNER

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

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

TEST_NON_SERIALIZED_APPS

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

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

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

THOUSAND_SEPARATOR

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

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

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

関連項目: NUMBER_GROUPING, DECIMAL_SEPARATOR, USE_THOUSAND_SEPARATOR

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_TZFalse のとき、これは Django が日時を保持するタイムゾーンとなります。USE_TZTrue のとき、これは 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は翻訳システムを読み込まないように一部の最適化を行います。

関連項目: LANGUAGE_CODE および USE_TZ

注釈

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

USE_THOUSAND_SEPARATOR

デフォルト値: False

真偽値で、数値を 1,000 単位で表示するかどうかを指定します。 True に設定すると、Django は数値を NUMBER_GROUPINGTHOUSAND_SEPARATOR の設定に従ってフォーマットします。最後の 2 つの設定はロケールによっても決定される可能性があり、そちらが優先されます。

関連項目: DECIMAL_SEPARATOR, NUMBER_GROUPING, THOUSAND_SEPARATOR

USE_TZ

デフォルト値: True

デフォルトで日時がタイムゾーンを意識するかどうかを指定する真偽値です。これが True に設定されている場合、Django は内部的にタイムゾーンを意識した日時を使用します。

USE_TZ が False の場合、Django はローカルタイムで naive な日時を使用しますが、ISO 8601 形式の文字列を解析するときには、タイムゾーン情報が存在すれば常に保持されます。

関連項目:TIME_ZONE および USE_I18N

Changed in Django 5.0:

古いバージョンでは、デフォルト値は False です。

USE_X_FORWARDED_HOST

デフォルト値: False

X-Forwarded-Host ヘッダを Host ヘッダより優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合にのみ有効化すべきです。

この設定は USE_X_FORWARDED_PORT よりも優先されます。RFC 7239#section-5.3 によると、X-Forwarded-Host ヘッダにはポート番号を含めることができるため、その場合は USE_X_FORWARDED_PORT を使用すべきではありません。

USE_X_FORWARDED_PORT

デフォルト値: False

X-Forwarded-Port ヘッダを SERVER_PORT META 変数より優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合のみ、これを有効にするべきです。

この設定より USE_X_FORWARDED_HOST の方が優先されます。

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_FORMATDATETIME_FORMATTIME_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_REDIRECT_URL

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

LoginViewnext GET パラメータを受け取らないときにログイン後にリダイレクトされる URL または 名前付き URL パターン

LOGIN_URL

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

login_required() デコレータ、 LoginRequiredMixin 、または AccessMixin を使用してログイン時にリダイレクトされるリクエストのURLまたは 名前付き URL パターン

LOGOUT_REDIRECT_URL

デフォルト値: None

リクエストがログアウト後にリダイレクトされるURLまたは 名前付きURLパターン で、 LogoutViewnext_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をご覧ください。

警告

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

STATIC_URL

デフォルト値: None

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

例: "static/" or "http://static.example.com/"

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

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

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

注釈

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

STATICFILES_DIRS

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

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

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

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_STORAGE

デフォルト値: 'django.contrib.staticfiles.storage.StaticFilesStorage'

collectstatic 管理コマンドで静的ファイルを収集する際に使用するファイルストレージエンジン。

この設定で定義されたストレージバックエンドのすぐ使えるインスタンスは、 django.core.files.storage.storagesstaticfiles キーの下に見つけることができます。

例については、 クラウドサービスや CDN から静的ファイルを配信する を参照してください。

バージョン 4.2 で非推奨: この設定は非推奨です。Django 4.2 から、静的ファイルのストレージエンジンは STORAGES 設定の staticfiles キーで設定できます。

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 によってアプリが見つけられるようにしてください。

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

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

ロギング

テンプレート

テスト

Back to Top