設定—Djangoドキュメント

提供：Dev Guides
< DjangoDjango/docs/3.2.x/ref/settings
移動先:案内、検索

設定

警告

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


コア設定

Djangoコアで利用可能な設定とそのデフォルト値のリストは次のとおりです。 contribアプリによって提供される設定を以下に示し、その後にコア設定のトピックインデックスを示します。 紹介資料については、設定トピックガイドを参照してください。

ABSOLUTE_URL_OVERRIDES

デフォルト：{}（空の辞書）

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

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

この設定で使用されるモデル名は、実際のモデルクラス名の大文字と小文字に関係なく、すべて小文字にする必要があります。


ADMINS

デフォルト：[]（空のリスト）

コードエラー通知を受け取るすべての人のリスト。 いつ ：setting： `DEBUG = False ` と AdminEmailHandler で構成されています ：setting： `LOGGING` （デフォルトで実行されます）、Djangoはこれらの人々に要求/応答サイクルで発生した例外の詳細を電子メールで送信します。

リストの各項目は、（フルネーム、電子メールアドレス）のタプルである必要があります。 例： 

[('John', '[email protected]'), ('Mary', '[email protected]')]

ALLOWED_HOSTS

デフォルト：[]（空のリスト）

このDjangoサイトが提供できるホスト/ドメイン名を表す文字列のリスト。 これは、 HTTPホストヘッダー攻撃を防ぐためのセキュリティ対策です。これは、一見安全と思われる多くのWebサーバー構成でも可能です。

このリストの値は、完全修飾名にすることができます（例： 'www.example.com'）。この場合、リクエストのHostヘッダーと正確に照合されます（大文字と小文字は区別されず、ポートは含まれません）。 ピリオドで始まる値は、サブドメインのワイルドカードとして使用できます。'.example.com'は、example.com、www.example.com、およびexample.comの他のサブドメインと一致します。 '*'の値は何にでも一致します。 この場合、Hostヘッダーの独自の検証を提供する責任があります（おそらくミドルウェアで。その場合、このミドルウェアは：setting： `MIDDLEWARE` で最初にリストする必要があります）。

Djangoでは、任意のエントリの完全修飾ドメイン名（FQDN）も許可されます。 一部のブラウザでは、Hostヘッダーに末尾のドットが含まれています。これは、ホストの検証を実行するときにDjangoが削除します。

Hostヘッダー（または：setting： `USE_X_FORWARDED_HOST` が有効な場合はX-Forwarded-Host）がこのリストのどの値とも一致しない場合、 django.http。 HttpRequest.get_host（）メソッドは、 SuspiciousOperation を発生させます。

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

ALLOWED_HOSTSは、テストの実行時にもチェックされます。

この検証は、 get_host（）を介してのみ適用されます。 コードがrequest.METAからHostヘッダーに直接アクセスする場合、このセキュリティ保護をバイパスしています。

バージョン3.1で変更： ALLOWED_HOSTSが空で、DEBUG=Trueの場合、ローカルホストのサブドメインが許可されていました。


APPEND_SLASH

デフォルト：True

Trueに設定すると、リクエストURLがURLconfのどのパターンとも一致せず、スラッシュで終わらない場合、スラッシュが追加された同じURLにHTTPリダイレクトが発行されます。 リダイレクトにより、POSTリクエストで送信されたデータが失われる可能性があることに注意してください。

：setting： `APPEND_SLASH` 設定は、 CommonMiddleware がインストールされている場合にのみ使用されます（ミドルウェアを参照）。 ：setting： `PREPEND_WWW` も参照してください。


CACHES

ディフォルト： 

{
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    }
}

Djangoで使用されるすべてのキャッシュの設定を含む辞書。 これはネストされたディクショナリであり、その内容はキャッシュエイリアスを個々のキャッシュのオプションを含むディクショナリにマップします。

：setting： `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に付属していないキャッシュバックエンドを使用できます ：setting： `バックエンド ` キャッシュバックエンドクラスの完全修飾パス（つまり、 mypackage.backends.whatever.WhateverCache）。

バージョン3.2で変更： PyMemcacheCacheバックエンドが追加されました。


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の場合、キャッシュエントリは期限切れになりません。


VERSION

デフォルト：1

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

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


CACHE_MIDDLEWARE_ALIAS

デフォルト：'default'

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


CACHE_MIDDLEWARE_KEY_PREFIX

デフォルト：（空の文字列）

キャッシュミドルウェアによって生成されたキャッシュキーのプレフィックスとなる文字列。 このプレフィックスは、 ：setting： `KEY_PREFIX ` 設定; それはそれを置き換えません。

Djangoのキャッシュフレームワークを参照してください。


CACHE_MIDDLEWARE_SECONDS

デフォルト：600

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

Djangoのキャッシュフレームワークを参照してください。


CSRF_USE_SESSIONS

デフォルト：False

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

CSRFトークンをCookie（Djangoのデフォルト）に保存することは安全ですが、セッションに保存することは他のWebフレームワークでは一般的な方法であるため、セキュリティ監査人から要求されることがあります。

デフォルトのエラービューにはCSRFトークンが必要なため、 SessionMiddleware は、エラーをトリガーする例外を発生させる可能性のあるミドルウェアの前に：setting： `MIDDLEWARE` に表示される必要がありますCSRF_USE_SESSIONSを使用している場合は、ビュー（ PermissionDenied など）。 ミドルウェアの注文を参照してください。


CSRF_FAILURE_VIEW

デフォルト：'django.views.csrf.csrf_failure'

CSRF保護によって着信要求が拒否されたときに使用されるビュー機能への点線のパス。 関数には次のシグネチャが必要です。 

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

ここで、reasonは、要求が拒否された理由を示す短いメッセージ（開発者またはロギングを対象としており、エンドユーザーを対象としていません）です。 HttpResponseForbidden を返す必要があります。

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


CSRF_HEADER_NAME

デフォルト：'HTTP_X_CSRFTOKEN'

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

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


CSRF_TRUSTED_ORIGINS

デフォルト：[]（空のリスト）

安全でないリクエストの信頼できる発信元であるホストのリスト（例： POST）。 セキュア安全でないリクエストの場合、DjangoのCSRF保護では、リクエストにHostヘッダーに存在するオリジンと一致するRefererヘッダーが必要です。 これにより、たとえば、subdomain.example.comからのPOST要求がapi.example.comに対して成功するのを防ぎます。 HTTPSを介したクロスオリジンの安全でないリクエストが必要な場合は、例を続けて、このリストに"subdomain.example.com"を追加します。 この設定はサブドメインもサポートしているため、たとえば".example.com"を追加して、example.comのすべてのサブドメインからのアクセスを許可できます。


DATABASES

デフォルト：{}（空の辞書）

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

：setting： `DATABASES` 設定では、defaultデータベースを構成する必要があります。 追加のデータベースをいくつでも指定できます。

最も単純な設定ファイルは、SQLiteを使用した単一データベースのセットアップ用です。 これは、以下を使用して構成できます。 

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

MariaDB、MySQL、Oracle、PostgreSQLなどの他のデータベースバックエンドに接続する場合は、追加の接続パラメーターが必要になります。 を参照してください ：setting： `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

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


ENGINE

デフォルト：（空の文字列）

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

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

ENGINEを完全修飾パス（つまり、 mypackage.backends.whatever）。


HOST

デフォルト：（空の文字列）

データベースに接続するときに使用するホスト。 空の文字列はローカルホストを意味します。 SQLiteでは使用されません。

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

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

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

PostgreSQLを使用している場合、デフォルト（空の：setting： `HOST` ）で、データベースへの接続はUNIXドメインソケット（pg_hba.confの「ローカル」行）を介して行われます。 UNIXドメインソケットが標準の場所にない場合は、postgresql.confと同じ値のunix_socket_directoryを使用してください。 TCPソケットを介して接続する場合は、：setting： `HOST` を 'localhost'または '127.0.0.1'（pg_hba.confの 'host'行）に設定します。 Windowsでは、UNIXドメインソケットが使用できないため、常に：setting： `HOST` を定義する必要があります。


NAME

デフォルト：（空の文字列）

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


CONN_MAX_AGE

デフォルト：0

秒の整数としてのデータベース接続の存続期間。 0を使用して、各リクエストの最後にデータベース接続を閉じます— Djangoの履歴動作—およびNoneを使用して、無制限の持続的接続を行います。


OPTIONS

デフォルト：{}（空の辞書）

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

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


PASSWORD

デフォルト：（空の文字列）

データベースに接続するときに使用するパスワード。 SQLiteでは使用されません。


PORT

デフォルト：（空の文字列）

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


TIME_ZONE

デフォルト：None

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

：setting： `USE_TZ` がTrueであり、このオプションが設定されている場合、データベースから日時を読み取ると、UTCではなくこのタイムゾーンの認識日時が返されます。 ：setting： `USE_TZ` がFalseの場合、このオプションを設定するとエラーになります。

  • データベースバックエンドがタイムゾーンをサポートしていない場合（例： SQLite、MySQL、Oracle）、Djangoは、設定されている場合はこのオプションに従って現地時間で、設定されていない場合はUTCで日時を読み書きします。

    接続タイムゾーンを変更すると、データベースからの日時の読み取り方法とデータベースへの書き込み方法が変更されます。

    • Djangoがデータベースを管理していて、それ以外の理由がない場合は、このオプションを未設定のままにしておく必要があります。 夏時間の変更中にあいまいな、または存在しない日時を回避するため、UTCで日時を保存することをお勧めします。 また、UTCで日時を受信すると、日時の計算が簡単になります。pytzが提供するnormalize()メソッドは必要ありません。

    • UTCではなく現地時間で日時を保存するサードパーティのデータベースに接続している場合は、このオプションを適切なタイムゾーンに設定する必要があります。 同様に、Djangoがデータベースを管理しているが、サードパーティのシステムが同じデータベースに接続し、現地時間で日時を見つけることを期待している場合は、このオプションを設定する必要があります。

  • データベースバックエンドがタイムゾーンをサポートしている場合（例： PostgreSQL）、TIME_ZONEオプションが必要になることはめったにありません。 いつでも変更できます。 データベースは、日時を目的のタイムゾーンに変換します。

    データベース接続のタイムゾーンを設定すると、結果がタイムゾーンに依存するため、date_truncなどのデータベースによって提供される日付/時刻関数を含む生のSQLクエリを実行するのに役立つ場合があります。

    ただし、これには欠点があります。すべての日時を現地時間で受け取ると、日時の計算が難しくなります。各操作の後に、pytzが提供するnormalize()メソッドを呼び出す必要があります。

    TIME_ZONEオプションを設定する代わりに、生のSQLクエリでAT TIME ZONEを使用して明示的に現地時間に変換することを検討してください。

バージョン3.1で変更：データベースバックエンドがタイムゾーンをサポートしている場合にこのオプションを使用することが許可されました。


DISABLE_SERVER_SIDE_CURSORS

デフォルト：False

QuerySet.iterator（）でサーバー側カーソルの使用を無効にする場合は、これをTrueに設定します。 トランザクションプーリングとサーバー側カーソルは、ユースケースについて説明しています。

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


USER

デフォルト：（空の文字列）

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


TEST

デフォルト：{}（空の辞書）

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

テストデータベース構成の例を次に示します。 

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

TESTディクショナリの次のキーを使用できます。

CHARSET

デフォルト：None

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

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


COLLATION

デフォルト：None

テストデータベースを作成するときに使用する照合順序。 この値はバックエンドに直接渡されるため、その形式はバックエンド固有です。

mysqlバックエンドでのみサポートされます（詳細については、 MySQLマニュアルを参照してください）。


DEPENDENCIES

デフォルト：['default']、default以外のすべてのデータベースで、依存関係はありません。

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


MIGRATE

バージョン3.1の新機能。


デフォルト：True

Falseに設定すると、テストデータベースの作成時に移行は実行されません。 これは、Noneを：setting： `MIGRATION_MODULES` の値として設定するのと似ていますが、すべてのアプリに適用されます。


MIRROR

デフォルト：None

このデータベースがテスト中にミラーリングする必要があるデータベースのエイリアス。

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


NAME

デフォルト：None

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

デフォルト値（None）がSQLiteデータベースエンジンで使用される場合、テストはメモリ常駐データベースを使用します。 他のすべてのデータベースエンジンの場合、テストデータベースは'test_' + DATABASE_NAMEという名前を使用します。

テストデータベースを参照してください。


SERIALIZE

デフォルトのテストランナーがテストを実行する前にデータベースをメモリ内のJSON文字列にシリアル化するかどうかを制御するブール値（トランザクションがない場合にテスト間でデータベースの状態を復元するために使用されます）。 serialized_rollback = True のテストクラスがない場合は、これをFalseに設定して、作成時間を短縮できます。


TEMPLATE

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

テンプレートの名前（例： '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）表領域が使用されます。 ：setting： `DATAFILE` および：setting：` DATAFILE_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.bodyまたはrequest.POSTにアクセスするときに実行され、ファイルアップロードデータを除いたリクエストの合計サイズに対して計算されます。 これをNoneに設定すると、チェックを無効にできます。 異常に大きなフォーム投稿を受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。

要求データの量は、要求を処理し、GETおよびPOSTディクショナリにデータを入力するために必要なメモリの量と相関しています。 大きなリクエストは、チェックしないままにしておくと、サービス拒否攻撃のベクトルとして使用される可能性があります。 Webサーバーは通常、詳細な要求検査を実行しないため、そのレベルで同様のチェックを実行することはできません。

：setting： `FILE_UPLOAD_MAX_MEMORY_SIZE` も参照してください。


DATA_UPLOAD_MAX_NUMBER_FIELDS

デフォルト：1000

SuspiciousOperation （TooManyFields）が発生する前に、GETまたはPOSTを介して受信できるパラメーターの最大数。 これをNoneに設定すると、チェックを無効にできます。 異常に多数のフォームフィールドを受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。

要求パラメーターの数は、要求を処理し、GETおよびPOSTディクショナリにデータを取り込むために必要な時間と相関関係があります。 大きなリクエストは、チェックしないままにしておくと、サービス拒否攻撃のベクトルとして使用される可能性があります。 Webサーバーは通常、詳細な要求検査を実行しないため、そのレベルで同様のチェックを実行することはできません。


DATABASE_ROUTERS

デフォルト：[]（空のリスト）

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

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


DATE_FORMAT

デフォルト：'N j, Y'（例： Feb. 4, 2003）

システムの任意の部分で日付フィールドを表示するために使用するデフォルトのフォーマット。 ：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。 見る ：tfilter： `許可された日付形式の文字列 ` 。

：setting： `DATETIME_FORMAT` 、：setting：` TIME_FORMAT` および：setting： `SHORT_DATE_FORMAT` も参照してください。


DATE_INPUT_FORMATS

ディフォルト： 

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

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

：setting： `USE_L10N` がTrueの場合、ロケールで指定された形式の方が優先され、代わりに適用されます。

：setting： `DATETIME_INPUT_FORMATS` および：setting：` TIME_INPUT_FORMATS` も参照してください。


DATETIME_FORMAT

デフォルト：'N j, Y, P'（例： Feb. 4, 2003, 4 p.m.）

システムの任意の部分で日時フィールドを表示するために使用するデフォルトのフォーマット。 ：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。 見る ：tfilter： `許可された日付形式の文字列 ` 。

：setting： `DATE_FORMAT` 、：setting：` TIME_FORMAT` および：setting： `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'
]

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

：setting： `USE_L10N` がTrueの場合、ロケールで指定された形式の方が優先され、代わりに適用されます。

：setting： `DATE_INPUT_FORMATS` および：setting：` TIME_INPUT_FORMATS` も参照してください。

バージョン3.1で変更：古いバージョンでは、デフォルトは日付のみの形式も含むリストです。


DEBUG

デフォルト：False

デバッグモードをオン/オフにするブール値。

：setting： `DEBUG` をオンにしてサイトを本番環境にデプロイしないでください。

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

セキュリティ対策として、Djangoには：setting： `SECRET_KEY` などの機密性の高い設定が含まれません。 具体的には、名前に次のいずれかが含まれる設定は除外されます。

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

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

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

：setting： `DEBUG` をオンにして実行すると、Djangoは実行するすべてのSQLクエリを記憶することを覚えておくことも重要です。 これはデバッグ時に役立ちますが、運用サーバーのメモリを急速に消費します。

最後に、：setting： `DEBUG` がFalseの場合、：setting：` ALLOWED_HOSTS` 設定も適切に設定する必要があります。 そうしないと、すべてのリクエストが「Bad Request（400）」として返されます。

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` セットDEBUG = True便宜上。


DEBUG_PROPAGATE_EXCEPTIONS

デフォルト：False

Trueに設定されている場合、Djangoのビュー関数の例外処理（ handler500 、または：setting： `DEBUG` がTrueの場合はデバッグビュー） 500応答のロギング（ django.request ）はスキップされ、例外は上方に伝播します。

これは、一部のテスト設定に役立ちます。 （Djangoの代わりに）Webサーバーで「内部サーバーエラー」応答を生成する場合を除いて、ライブサイトでは使用しないでください。 その場合、サーバーが応答にスタックトレースやその他の機密情報を表示しないようにしてください。


DECIMAL_SEPARATOR

デフォルト：'.'（ドット）

10進数をフォーマットするときに使用されるデフォルトの小数点。

：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。

：setting： `NUMBER_GROUPING` 、：setting：` THOUSAND_SEPARATOR` および：setting： `USE_THOUSAND_SEPARATOR` も参照してください。


DEFAULT_AUTO_FIELD

バージョン3.2の新機能。


デフォルト：' django.db.models.AutoField '

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

テーブルを介して自動作成されたものの移行

DEFAULT_AUTO_FIELDの値は、多対多の関係のテーブルを介して自動作成された新しいものを作成するときに尊重されます。

残念ながら、テーブルを介して自動作成された既存の主キーは、現在、移行フレームワークによって更新できません。

つまり、DEFAULT_AUTO_FIELDの値を切り替えてから移行を生成すると、関連モデルの主キーが更新されます。スルーテーブルの外部キーも更新されますが、自動作成された主キーは更新されます。スルーテーブルは移行されません。

これに対処するには、 RunSQL 操作を移行に追加して、必要なALTER TABLEステップを実行する必要があります。 sqlmigrate、dbshellを介して、またはフィールドのremote_field.through._meta.db_tableプロパティを使用して、既存のテーブル名を確認できます。

モデルを介して明示的に定義されたものは、移行システムによってすでに処理されています。

テーブルを介して自動作成された既存の主キーの自動移行を許可する ：ticket： `後日実装される可能性があります<32674>` 。


DEFAULT_CHARSET

デフォルト：'utf-8'

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


DEFAULT_EXCEPTION_REPORTER

バージョン3.1の新機能。


デフォルト：' django.views.debug.ExceptionReporter '

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


DEFAULT_EXCEPTION_REPORTER_FILTER

デフォルト：' django.views.debug.SafeExceptionReporterFilter '

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


DEFAULT_FILE_STORAGE

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

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


DEFAULT_FROM_EMAIL

デフォルト：'webmaster@localhost'

サイト管理者からのさまざまな自動通信に使用するデフォルトの電子メールアドレス。 これには、：setting： `ADMINS` および：setting：` MANAGERS` に送信されるエラーメッセージは含まれません。 そのためには、：setting： `SERVER_EMAIL` を参照してください。


DEFAULT_HASHING_ALGORITHM

バージョン3.1の新機能。


デフォルト：'sha256'

django.core.signing.Signer および django.core.signing.dumps（）によって作成されたCookie、管理サイトのパスワードリセットトークン、ユーザーセッション、および署名のエンコードに使用するデフォルトのハッシュアルゴリズム。 アルゴリズムは'sha1'または'sha256'である必要があります。 使用方法の詳細については、リリースノートを参照してください。

バージョン3.1以降非推奨：この移行設定は非推奨です。 それと、SHA-1ハッシュアルゴリズムを使用するトークン、Cookie、セッション、および署名のサポートは、Django4.0で削除されます。


DEFAULT_INDEX_TABLESPACE

デフォルト：（空の文字列）

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


DEFAULT_TABLESPACE

デフォルト：（空の文字列）

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


DISALLOWED_USER_AGENTS

デフォルト：[]（空のリスト）

システム全体で、どのページにもアクセスできないUser-Agent文字列を表すコンパイル済み正規表現オブジェクトのリスト。 ボット/クローラーにこれを使用します。 これは、CommonMiddlewareがインストールされている場合にのみ使用されます（ミドルウェアを参照）。


EMAIL_BACKEND

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

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


EMAIL_FILE_PATH

デフォルト：未定義

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

バージョン3.1で変更： pathlib.Pathのサポートが追加されました。


EMAIL_HOST

デフォルト：'localhost'

電子メールの送信に使用するホスト。

：setting： `EMAIL_PORT` も参照してください。


EMAIL_HOST_PASSWORD

デフォルト：（空の文字列）

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

：setting： `EMAIL_HOST_USER` も参照してください。


EMAIL_HOST_USER

デフォルト：（空の文字列）

：setting： `EMAIL_HOST` で定義されているSMTPサーバーに使用するユーザー名。 空の場合、Djangoは認証を試みません。

：setting： `EMAIL_HOST_PASSWORD` も参照してください。


EMAIL_PORT

デフォルト：25

：setting： `EMAIL_HOST` で定義されているSMTPサーバーに使用するポート。


EMAIL_SUBJECT_PREFIX

デフォルト：'[Django] '

django.core.mail.mail_adminsまたはdjango.core.mail.mail_managersで送信される電子メールメッセージの件名プレフィックス。 おそらく、末尾のスペースを含めることをお勧めします。


EMAIL_USE_LOCALTIME

デフォルト：False

電子メールメッセージのSMTP Dateヘッダーをローカルタイムゾーン（True）またはUTC（False）のどちらで送信するか。


EMAIL_USE_TLS

デフォルト：False

SMTPサーバーと通信するときにTLS（セキュア）接続を使用するかどうか。 これは、通常はポート587での明示的なTLS接続に使用されます。 接続がハングする場合は、暗黙のTLS設定：setting： `EMAIL_USE_SSL` を参照してください。


EMAIL_USE_SSL

デフォルト：False

SMTPサーバーと通信するときに暗黙のTLS（セキュア）接続を使用するかどうか。 ほとんどの電子メールドキュメントでは、このタイプのTLS接続はSSLと呼ばれています。 通常、ポート465で使用されます。 問題が発生している場合は、明示的なTLS設定：setting： `EMAIL_USE_TLS` を参照してください。

：setting： `EMAIL_USE_TLS` / ：setting：` EMAIL_USE_SSL` は相互に排他的であるため、これらの設定の1つのみをTrueに設定することに注意してください。


EMAIL_SSL_CERTFILE

デフォルト：None

：setting： `EMAIL_USE_SSL` または：setting：` EMAIL_USE_TLS` がTrueの場合、オプションで、使用するPEM形式の証明書チェーンファイルへのパスを指定できます。 SSL接続用。


EMAIL_SSL_KEYFILE

デフォルト：None

：setting： `EMAIL_USE_SSL` または：setting：` EMAIL_USE_TLS` がTrueの場合、オプションで、使用するPEM形式の秘密鍵ファイルへのパスを指定できます。 SSL接続用。

：setting： `EMAIL_SSL_CERTFILE` および：setting：` EMAIL_SSL_KEYFILE` を設定しても、証明書はチェックされないことに注意してください。 それらは基礎となるSSL接続に渡されます。 証明書チェーンファイルと秘密鍵ファイルの処理方法の詳細については、Pythonのpython:ssl.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）。

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

：setting： `DATA_UPLOAD_MAX_MEMORY_SIZE` も参照してください。


FILE_UPLOAD_DIRECTORY_PERMISSIONS

デフォルト：None

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

この設定は、：djadmin： `collectstatic` 管理コマンドを使用するときに収集される静的ディレクトリのデフォルトの権限も決定します。 オーバーライドの詳細については、：djadmin： `collectstatic` を参照してください。

この値は、：setting： `FILE_UPLOAD_PERMISSIONS` 設定の機能と警告を反映しています。


FILE_UPLOAD_PERMISSIONS

デフォルト：0o644

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

Noneの場合、オペレーティングシステムに依存する動作が発生します。 ほとんどのプラットフォームでは、一時ファイルのモードは0o600であり、メモリから保存されたファイルは、システムの標準umaskを使用して保存されます。

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

この設定は、：djadmin： `collectstatic` 管理コマンドを使用するときに収集される静的ファイルのデフォルトのアクセス許可も決定します。 オーバーライドの詳細については、：djadmin： `collectstatic` を参照してください。

警告

モードの前には常に接頭辞を付けてください 0o .

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


FILE_UPLOAD_TEMP_DIR

デフォルト：None

ファイルのアップロード中に一時的にデータを保存するディレクトリ（通常は：setting： `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 を実装する必要があります。 含まれているフォームレンダラーは次のとおりです。


FORMAT_MODULE_PATH

デフォルト：None

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

たとえば、：setting： `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パスを通過します。 これは、リストのさらに上のパッケージで定義されたフォーマットが、より下のパッケージの同じフォーマットよりも優先されることを意味します。

使用可能な形式は次のとおりです。


IGNORABLE_404_URLS

デフォルト：[]（空のリスト）

電子メールでHTTP404エラーを報告するときに無視する必要があるURLを説明するコンパイル済み正規表現オブジェクトのリスト（エラー報告を参照）。 正規表現は、リクエスト'のフルパス（クエリ文字列がある場合はそれを含む）と照合されます。 サイトがfavicon.icoやrobots.txtなどの一般的に要求されるファイルを提供していない場合にこれを使用します。

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


INSTALLED_APPS

デフォルト：[]（空のリスト）

このDjangoインストールで有効になっているすべてのアプリケーションを指定する文字列のリスト。 各文字列は、次の場所への点線のPythonパスである必要があります。

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

アプリケーション構成の詳細。

イントロスペクションにはアプリケーションレジストリを使用します

コードが：setting： `INSTALLED_APPS` に直接アクセスしないようにしてください。 代わりに django.apps.apps を使用してください。


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

アプリケーション names —アプリケーションパッケージへの点線のPythonパス—は一意である必要があります。 別の名前でコードを複製する以外に、同じアプリケーションを2回含める方法はありません。

アプリケーション labels —デフォルトでは名前の最後の部分—も一意である必要があります。 たとえば、django.contrib.authとmyproject.authの両方を含めることはできません。 ただし、別の label を定義するカスタム構成でアプリケーションにラベルを付け直すことができます。

これらのルールは、：setting： `INSTALLED_APPS` がアプリケーション構成クラスまたはアプリケーションパッケージを参照するかどうかに関係なく適用されます。


複数のアプリケーションが同じリソース（テンプレート、静的ファイル、管理コマンド、変換）の異なるバージョンを提供する場合、：setting： `INSTALLED_APPS` に最初にリストされているアプリケーションが優先されます。


INTERNAL_IPS

デフォルト：[]（空のリスト）

文字列としてのIPアドレスのリスト。

  • debug（）コンテキストプロセッサがいくつかの変数をテンプレートコンテキストに追加できるようにします。
  • スタッフユーザーとしてログインしていなくても、 admindocsブックマークレットを使用できます。
  • AdminEmailHandler の電子メールでは、（「EXTERNAL」ではなく）「内部」としてマークされています。


LANGUAGE_CODE

デフォルト：'en-us'

このインストールの言語コードを表す文字列。 これは、標準の言語ID形式である必要があります。 たとえば、米国 英語は"en-us"です。 言語識別子のリストおよび国際化とローカリゼーションも参照してください。

：setting： `USE_I18N` は、この設定を有効にするにはアクティブである必要があります。

それは2つの目的を果たします：

  • ロケールミドルウェアが使用されていない場合は、すべてのユーザーに提供される翻訳を決定します。
  • ロケールミドルウェアがアクティブな場合、ユーザーの優先言語を決定できないか、Webサイトでサポートされていない場合に備えて、フォールバック言語を提供します。 また、特定のリテラルの翻訳がユーザーの優先言語に存在しない場合のフォールバック翻訳も提供します。

詳細については、 Djangoが言語設定を検出する方法を参照してください。


LANGUAGES

デフォルト：使用可能なすべての言語のリスト。 このリストは絶えず増え続けており、ここにコピーを含めると、必然的に急速に古くなります。 ：source： `django / conf / global_settings.py` を見ると、翻訳された言語の現在のリストを確認できます。

このリストは、言語コード、language name）の形式の2つのタプルのリストです（例：('ja', 'Japanese')）。 これは、言語選択に使用できる言語を指定します。 国際化とローカリゼーションを参照してください。

通常、デフォルト値で十分です。 言語の選択をDjangoが提供する言語のサブセットに制限する場合にのみ、この設定を設定してください。

カスタム：setting： `LANGUAGES` 設定を定義する場合、 gettext_lazy（）関数を使用して言語名を翻訳文字列としてマークできます。

サンプル設定ファイルは次のとおりです。 

from django.utils.translation import gettext_lazy as _

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

LANGUAGES_BIDI

デフォルト：右から左に書かれているすべての言語コードのリスト。 ：source： `django / conf / global_settings.py` を見ると、これらの言語の現在のリストを確認できます。

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

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


LOCALE_PATHS

デフォルト：[]（空のリスト）

Djangoが翻訳ファイルを探すディレクトリのリスト。 Djangoが翻訳を検出する方法を参照してください。

例： 

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

Djangoは、これらの各パス内で、実際の翻訳ファイルを含む<locale_code>/LC_MESSAGESディレクトリを探します。


LOGGING

デフォルト：ロギング構成ディクショナリ。

構成情報を含むデータ構造。 このデータ構造の内容は、：setting： `LOGGING_CONFIG` で説明されている構成メソッドに引数として渡されます。

特に、：setting： `DEBUG` がFalseの場合、デフォルトのロギング構成はHTTP500サーバーエラーを電子メールログハンドラーに渡します。 ロギングの構成も参照してください。

：source： `django / utils / log.py` を調べると、デフォルトのログ設定を確認できます。


LOGGING_CONFIG

デフォルト：'logging.config.dictConfig'

Djangoプロジェクトのロギングを構成するために使用される呼び出し可能オブジェクトへのパス。 デフォルトでは、Pythonの dictConfig 構成メソッドのインスタンスを指します。

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


MANAGERS

デフォルト：[]（空のリスト）

：setting： `ADMINS` と同じ形式のリストで、 BrokenLinkEmailsMiddleware が有効になっている場合にリンク切れ通知を受け取るユーザーを指定します。


MEDIA_ROOT

デフォルト：（空の文字列）

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

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

：setting： `MEDIA_URL` も参照してください。

警告

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


MEDIA_URL

デフォルト：（空の文字列）

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

テンプレートでテンプレート:MEDIA URLを使用する場合は、：setting： `TEMPLATES` の'context_processors'オプションに'django.template.context_processors.media'を追加します。

例："http://media.example.com/%22

警告

信頼できないユーザーからアップロードされたコンテンツを受け入れる場合、セキュリティ上のリスクがあります。 緩和策の詳細については、ユーザーがアップロードしたコンテンツに関するセキュリティガイドのトピックを参照してください。


警告

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


ノート

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


MIDDLEWARE

デフォルト：None

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


MIGRATION_MODULES

デフォルト：{}（空の辞書）

アプリごとに移行モジュールを見つけることができるパッケージを指定する辞書。 この設定のデフォルト値は空のディクショナリですが、移行モジュールのデフォルトのパッケージ名はmigrationsです。

例： 

{'blog': 'blog.db_migrations'}

この場合、blogアプリに関連する移行はblog.db_migrationsパッケージに含まれます。

app_label引数を指定すると、：djadmin： `makemigrations` は、パッケージがまだ存在しない場合は自動的に作成します。

アプリの値としてNoneを指定すると、Djangoは、既存のmigrationsサブモジュールに関係なく、アプリを移行のないアプリと見なします。 これは、たとえば、テスト設定ファイルで使用して、テスト中の移行をスキップできます（アプリのモデル用のテーブルは引き続き作成されます）。 テスト中にすべてのアプリの移行を無効にするには、 ：setting： `MIGRATE ` にFalse代わりは。 一般的なプロジェクト設定でMIGRATION_MODULESが使用されている場合、アプリのテーブルを作成する場合は、migrate --run-syncdbオプションを使用することを忘れないでください。


MONTH_DAY_FORMAT

デフォルト：'F j'

月と日のみが表示される場合に、Django管理者変更リストページの日付フィールドに使用するデフォルトのフォーマット（場合によってはシステムの他の部分）。

たとえば、Django管理者の変更リストページが日付ドリルダウンによってフィルタリングされている場合、特定の日のヘッダーには日と月が表示されます。 ロケールが異なれば、フォーマットも異なります。 たとえば、米国 英語は「1月1日」と言いますが、スペイン語は「1エネロ」と言うかもしれません。

：setting： `USE_L10N` がTrueに設定されている場合、対応するロケール指定の形式が優先され、適用されることに注意してください。

見る ：tfilter： `許可された日付形式の文字列 ` 。 ：setting： `DATE_FORMAT` 、：setting：` DATETIME_FORMAT` 、：setting： `TIME_FORMAT` 、：setting：` YEAR_MONTH_FORMAT`も参照してください。 。


NUMBER_GROUPING

デフォルト：0

数値の整数部分にグループ化された桁数。

一般的な使用法は、千単位の区切り文字を表示することです。 この設定が0の場合、グループ化は番号に適用されません。 この設定が0より大きい場合、：setting： `THOUSAND_SEPARATOR` がこれらのグループ間の区切り文字として使用されます。

一部のロケールでは、不均一な数字のグループ化が使用されます。 en_INの10,00,00,000。 この場合、適用する桁グループサイズの数をシーケンスに指定できます。 最初の数字は小数点の前のグループのサイズを定義し、その後の各数字は前のグループのサイズを定義します。 シーケンスが-1で終了している場合、それ以上のグループ化は実行されません。 シーケンスが0で終了する場合、最後のグループサイズが残りの数に使用されます。

en_INのタプルの例： 

NUMBER_GROUPING = (3, 2, 0)

：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。

：setting： `DECIMAL_SEPARATOR` 、：setting：` THOUSAND_SEPARATOR` および：setting： `USE_THOUSAND_SEPARATOR` も参照してください。


PREPEND_WWW

デフォルト：False

「www」を前に付けるかどうか。 それを持たないURLへのサブドメイン。 これは、 CommonMiddleware がインストールされている場合にのみ使用されます（ミドルウェアを参照）。 ：setting： `APPEND_SLASH` も参照してください。


ROOT_URLCONF

デフォルト：未定義

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


SECRET_KEY

デフォルト：（空の文字列）

特定のDjangoインストールの秘密鍵。 これは、暗号署名を提供するために使用され、一意の予測できない値に設定する必要があります。

：djadmin： `django-admin startproject ` ランダムに生成されたものを自動的に追加しますSECRET_KEYそれぞれの新しいプロジェクトに。

キーの使用は、それがテキストまたはバイトであると想定するべきではありません。 すべての使用は、 force_str（）または force_bytes（）を実行して、目的のタイプに変換する必要があります。

：setting： `SECRET_KEY` が設定されていない場合、Djangoは起動を拒否します。

警告

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

既知の：setting： `SECRET_KEY` を使用してDjangoを実行すると、Djangoのセキュリティ保護の多くが無効になり、特権の昇格やリモートでのコード実行の脆弱性が発生する可能性があります。


秘密鍵は次の目的で使用されます。

秘密鍵をローテーションすると、上記のすべてが無効になります。 秘密鍵はユーザーのパスワードには使用されず、鍵のローテーションはユーザーに影響を与えません。

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` ユニークなSECRET_KEY便宜上。


SECURE_BROWSER_XSS_FILTER

デフォルト：False

Trueの場合、 SecurityMiddleware は X-XSS-Protectionを1に設定します。 まだ持っていないすべての応答のmode = block ヘッダー。

最近のブラウザは、X-XSS-Protection HTTPヘッダーを尊重しなくなりました。 この設定は実用的なメリットはほとんどありませんが、古いブラウザをサポートしている場合は、ヘッダーを設定することをお勧めします。


SECURE_CONTENT_TYPE_NOSNIFF

デフォルト：True

Trueの場合、 SecurityMiddleware は、 X-Content-Type-Options：nosniff ヘッダーをまだ持っていないすべての応答に設定します。


SECURE_HSTS_INCLUDE_SUBDOMAINS

デフォルト：False

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

警告

これを誤って設定すると、不可逆的に（：setting： `SECURE_HSTS_SECONDS` の値の場合）サイトが破損する可能性があります。 最初に HTTP Strict Transport Security のドキュメントをお読みください。


SECURE_HSTS_PRELOAD

デフォルト：False

Trueの場合、 SecurityMiddleware はpreloadディレクティブを HTTP Strict Transport Security ヘッダーに追加します。 ：setting： `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以外の接続がある場合、エンドユーザーがHTTPS経由でリクエストした場合でも、is_secure()は常にFalseを返します。 対照的に、プロキシとDjangoの間にHTTPS接続がある場合、is_secure()は常にTrueを返します-元々HTTP経由で行われたリクエストの場合でも。

この状況では、リクエストがHTTPS経由で受信されたかどうかをDjangoに通知するカスタムHTTPヘッダーを設定するようにプロキシを構成し、Djangoが検索するヘッダーを認識できるようにSECURE_PROXY_SSL_HEADERを設定します。

検索するヘッダーの名前と必要な値の2つの要素でタプルを設定します。 例えば： 

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

これにより、DjangoはプロキシからのX-Forwarded-Protoヘッダーを信頼するようになり、その値が'https'の場合はいつでも、リクエストは安全であることが保証されます（つまり、元々HTTPS経由で受信されました）。 。

プロキシを制御する場合、またはこのヘッダーを適切に設定/削除するその他の保証がある場合は、のみでこの設定を設定する必要があります。

ヘッダーは、request.METAで使用される形式である必要があることに注意してください。すべて大文字で、HTTP_で始まる可能性があります。 （Djangoは、ヘッダーをrequest.METAで使用できるようにする前に、xヘッダー名の先頭に'HTTP_'を自動的に追加することを忘れないでください。）

警告

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

これを設定する前に、次のすべてが当てはまることを確認してください（上記の例の値を想定）。

  • Djangoアプリはプロキシの背後にあります。
  • プロキシは、すべての着信要求からX-Forwarded-Protoヘッダーを取り除きます。 つまり、エンドユーザーがそのヘッダーをリクエストに含めると、プロキシはそれを破棄します。
  • プロキシはX-Forwarded-Protoヘッダーを設定し、それをDjangoに送信しますが、これは元々HTTPS経由で受信されたリクエストに対してのみです。

これらのいずれかが当てはまらない場合は、この設定をNoneに設定したままにして、おそらくカスタムミドルウェアを介してHTTPSを決定する別の方法を見つける必要があります。


SECURE_REDIRECT_EXEMPT

デフォルト：[]（空のリスト）

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


SECURE_REFERRER_POLICY

デフォルト：'same-origin'

構成されている場合、 SecurityMiddleware は、 Referrer Policy ヘッダーを、まだ提供されていないすべての応答に設定します。

バージョン3.1で変更：古いバージョンでは、デフォルト値はNoneです。


SECURE_SSL_HOST

デフォルト：None

文字列の場合（例： secure.example.com）、すべてのSSLリダイレクトは、最初に要求されたホストではなく、このホストに送信されます（例： www.example.com）。 ：setting： `SECURE_SSL_REDIRECT` がFalseの場合、この設定は効果がありません。


SECURE_SSL_REDIRECT

デフォルト：False

Trueの場合、 SecurityMiddleware はすべての非HTTPSリクエストをHTTPSにリダイレクトします（：setting： `SECURE_REDIRECT_EXEMPT`にリストされている正規表現に一致するURLを除く） ）。

ノート

これをTrueにすると、リダイレクトが無限に発生する場合は、サイトがプロキシの背後で実行されており、安全なリクエストとそうでないリクエストを区別できない可能性があります。 プロキシは、安全な要求を示すヘッダーを設定する可能性があります。 そのヘッダーが何であるかを調べ、それに応じて：setting： `SECURE_PROXY_SSL_HEADER` 設定を構成することで、問題を修正できます。


SERIALIZATION_MODULES

デフォルト：未定義

そのシリアル化タイプの文字列識別子によってキー設定された、シリアライザー定義（文字列として提供）を含むモジュールの辞書。 たとえば、YAMLシリアライザーを定義するには、次を使用します。 

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

SERVER_EMAIL

デフォルト：'root@localhost'

：setting： `ADMINS` や：setting：` MANAGERS` に送信されたものなど、エラーメッセージの送信元の電子メールアドレス。

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

このアドレスは、エラーメッセージにのみ使用されます。 send_mail（）で送信される通常の電子メールメッセージの送信元のアドレスはではありません。 詳しくは、：setting： `DEFAULT_FROM_EMAIL` をご覧ください。


SHORT_DATE_FORMAT

デフォルト：'m/d/Y'（例： 12/31/2003）

テンプレートに日付フィールドを表示するために使用できる使用可能なフォーマット。 ：setting： `USE_L10N` がTrueに設定されている場合、対応するロケール指定の形式が優先され、適用されることに注意してください。 見る ：tfilter： `許可された日付形式の文字列 ` 。

：setting： `DATE_FORMAT` および：setting：` SHORT_DATETIME_FORMAT` も参照してください。


SHORT_DATETIME_FORMAT

デフォルト：'m/d/Y P'（例： 12/31/2003 4 p.m.）

テンプレートに日時フィールドを表示するために使用できる利用可能なフォーマット。 ：setting： `USE_L10N` がTrueに設定されている場合、対応するロケール指定の形式が優先され、適用されることに注意してください。 見る ：tfilter： `許可された日付形式の文字列 ` 。

：setting： `DATE_FORMAT` および：setting：` SHORT_DATE_FORMAT` も参照してください。


SIGNING_BACKEND

デフォルト：'django.core.signing.TimestampSigner'

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

暗号署名のドキュメントも参照してください。


SILENCED_SYSTEM_CHECKS

デフォルト：[]（空のリスト）

システムチェックフレームワークによって生成されたメッセージの識別子のリスト（つまり、 ["models.W001"]）永続的に確認して無視したい。 沈黙した小切手はコンソールに出力されません。

システムチェックフレームワークのドキュメントも参照してください。


TEMPLATES

デフォルト：[]（空のリスト）

Djangoで使用されるすべてのテンプレートエンジンの設定を含むリスト。 リストの各項目は、個々のエンジンのオプションを含む辞書です。

インストールされている各アプリケーション内のtemplatesサブディレクトリからテンプレートをロードするようにDjangoテンプレートエンジンに指示する設定は次のとおりです。 

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'APP_DIRS': True,
    },
]

次のオプションは、すべてのバックエンドで使用できます。

BACKEND

デフォルト：未定義

使用するテンプレートバックエンド。 組み込みのテンプレートバックエンドは次のとおりです。

  • 'django.template.backends.django.DjangoTemplates'
  • 'django.template.backends.jinja2.Jinja2'

BACKENDを完全修飾パスに設定することで、Djangoに付属していないテンプレートバックエンドを使用できます（つまり、 'mypackage.whatever.Backend'）。


NAME

デフォルト：以下を参照

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

デフォルトでは、エンジンクラスを定義するモジュールの名前になります。 最後から2番目の ：setting： `バックエンド ` 、提供されていない場合。 たとえば、バックエンドが'mypackage.whatever.Backend'の場合、デフォルト名は'whatever'です。


DIRS

デフォルト：[]（空のリスト）

エンジンがテンプレートソースファイルを検索順に検索するディレクトリ。


APP_DIRS

デフォルト：False

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

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` セット'APP_DIRS': True 。


OPTIONS

デフォルト：{}（空のdict）

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


TEST_RUNNER

デフォルト：'django.test.runner.DiscoverRunner'

テストスイートの開始に使用するクラスの名前。 さまざまなテストフレームワークの使用を参照してください。


TEST_NON_SERIALIZED_APPS

デフォルト：[]（空のリスト）

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

これにより、テストランナーの起動時間が遅くなります。 この機能を必要としないことがわかっているアプリがある場合は、ここにフルネームを追加できます（例： 'django.contrib.contenttypes'）これらをこのシリアル化プロセスから除外します。


THOUSAND_SEPARATOR

デフォルト：','（カンマ）

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

：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。

：setting： `NUMBER_GROUPING` 、：setting：` DECIMAL_SEPARATOR` および：setting： `USE_THOUSAND_SEPARATOR` も参照してください。


TIME_FORMAT

デフォルト：'P'（例： 4 p.m.）

システムの任意の部分で時間フィールドを表示するために使用するデフォルトのフォーマット。 ：setting： `USE_L10N` がTrueに設定されている場合は、ロケールで指定された形式の方が優先され、代わりに適用されることに注意してください。 見る ：tfilter： `許可された日付形式の文字列 ` 。

：setting： `DATE_FORMAT` および：setting：` DATETIME_FORMAT` も参照してください。


TIME_INPUT_FORMATS

ディフォルト： 

[
    '%H:%M:%S',     # '14:30:59'
    '%H:%M:%S.%f',  # '14:30:59.000200'
    '%H:%M',        # '14:30'
]

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

：setting： `USE_L10N` がTrueの場合、ロケールで指定された形式の方が優先され、代わりに適用されます。

：setting： `DATE_INPUT_FORMATS` および：setting：` DATETIME_INPUT_FORMATS` も参照してください。


TIME_ZONE

デフォルト：'America/Chicago'

このインストールのタイムゾーンを表す文字列。 タイムゾーンのリストを参照してください。

ノート

Djangoは：setting： `TIME_ZONE` を'America/Chicago'に設定して最初にリリースされたため、グローバル設定（プロジェクトのsettings.pyで何も定義されていない場合に使用）は'America/Chicago'下位互換性のため。 新しいプロジェクトテンプレートのデフォルトは'UTC'です。


これは必ずしもサーバーのタイムゾーンではないことに注意してください。 たとえば、1つのサーバーが複数のDjangoを利用したサイトにサービスを提供し、それぞれに個別のタイムゾーン設定が設定されている場合があります。

：setting： `USE_TZ` がFalseの場合、これはDjangoがすべての日時を保存するタイムゾーンです。 ：setting： `USE_TZ` がTrueの場合、これはDjangoがテンプレートに日時を表示し、フォームに入力された日時を解釈するために使用するデフォルトのタイムゾーンです。

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

ノート

Djangoは、Windows環境で代替タイムゾーンを確実に使用することはできません。 WindowsでDjangoを実行している場合は、：setting： `TIME_ZONE` をシステムのタイムゾーンに一致するように設定する必要があります。


USE_I18N

デフォルト：True

Djangoの翻訳システムを有効にするかどうかを指定するブール値。 これは、パフォーマンスのためにオフにする方法を提供します。 これがFalseに設定されている場合、Djangoは変換機構をロードしないようにいくつかの最適化を行います。

：setting： `LANGUAGE_CODE` 、：setting：` USE_L10N` 、：setting： `USE_TZ` も参照してください。

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` 含まれていますUSE_I18N = True便宜上。


USE_L10N

デフォルト：False

データのローカライズされたフォーマットをデフォルトで有効にするかどうかを指定するブール値。 これがTrueに設定されている場合、例： Djangoは、現在のロケールの形式を使用して数値と日付を表示します。

：setting： `LANGUAGE_CODE` 、：setting：` USE_I18N` 、：setting： `USE_TZ` も参照してください。

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` 含まれていますUSE_L10N = True便宜上。


USE_THOUSAND_SEPARATOR

デフォルト：False

1000区切り文字を使用して数値を表示するかどうかを指定するブール値。 Trueおよび：setting： `USE_L10N` もTrueに設定されている場合、Djangoは：setting：` NUMBER_GROUPING` および：setting： `THOUSAND_SEPARATOR` 設定。 これらの設定は、優先されるロケールによって決定される場合もあります。

：setting： `DECIMAL_SEPARATOR` 、：setting：` NUMBER_GROUPING` および：setting： `THOUSAND_SEPARATOR` も参照してください。


USE_TZ

デフォルト：False

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

USE_TZがFalseの場合、Djangoは現地時間でナイーブな日時を使用します。ただし、ISO 8601形式の文字列を解析する場合は除き、タイムゾーン情報が存在する場合は常に保持されます。

：setting： `TIME_ZONE` 、：setting：` USE_I18N` 、：setting： `USE_L10N` も参照してください。

ノート

デフォルトsettings.pyによって作成されたファイル ：djadmin： `django-admin startproject ` 含まれていますUSE_TZ = True便宜上。


USE_X_FORWARDED_HOST

デフォルト：False

HostヘッダーよりもX-Forwarded-Hostヘッダーを使用するかどうかを指定するブール値。 これは、このヘッダーを設定するプロキシが使用されている場合にのみ有効にする必要があります。

この設定は、：setting： `USE_X_FORWARDED_PORT` よりも優先されます。 RFC 7239＃section-5.3 に従って、X-Forwarded-Hostヘッダーにポート番号を含めることができます。この場合、：setting： `USE_X_FORWARDED_PORTを使用しないでください。 `。


USE_X_FORWARDED_PORT

デフォルト：False

SERVER_PORT META変数よりもX-Forwarded-Portヘッダーを使用するかどうかを指定するブール値。 これは、このヘッダーを設定するプロキシが使用されている場合にのみ有効にする必要があります。

：setting： `USE_X_FORWARDED_HOST` はこの設定よりも優先されます。


WSGI_APPLICATION

デフォルト：None

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

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


YEAR_MONTH_FORMAT

デフォルト：'F Y'

年と月のみが表示される場合に、Django管理者変更リストページの日付フィールドに使用するデフォルトのフォーマット（場合によってはシステムの他の部分）。

たとえば、Django管理者の変更リストページが日付ドリルダウンによってフィルタリングされている場合、特定の月のヘッダーには月と年が表示されます。 ロケールが異なれば、フォーマットも異なります。 たとえば、米国 英語では「2006年1月」と表示されますが、別のロケールでは「2006年/ 1月」と表示される場合があります。

：setting： `USE_L10N` がTrueに設定されている場合、対応するロケール指定の形式が優先され、適用されることに注意してください。

見る ：tfilter： `許可された日付形式の文字列 ` 。 ：setting： `DATE_FORMAT` 、：setting：` DATETIME_FORMAT` 、：setting： `TIME_FORMAT` 、：setting：` 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'

ユーザーを表すために使用するモデル。 カスタムユーザーモデルの置換を参照してください。

警告

プロジェクトの存続期間中（つまり、AUTH_USER_MODEL設定を変更することはできません） それに依存するモデルを作成して移行したら、真剣な努力なしに）。 これはプロジェクトの開始時に設定することを目的としており、参照するモデルは、それが存在するアプリの最初の移行で使用可能である必要があります。 詳細については、カスタムユーザーモデルの置換を参照してください。


LOGIN_REDIRECT_URL

デフォルト：'/accounts/profile/'

LoginView がnext GETパラメーターを取得しない場合に、ログイン後にリクエストがリダイレクトされるURLまたは名前付きURLパターン。


LOGIN_URL

デフォルト：'/accounts/login/'

login_required（）デコレータ、 LoginRequiredMixin 、または AccessMixin を使用するときに、リクエストがログイン用にリダイレクトされるURLまたは名前付きURLパターン。


LOGOUT_REDIRECT_URL

デフォルト：None

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

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


PASSWORD_RESET_TIMEOUT

バージョン3.1の新機能。


デフォルト：259200（3日、秒単位）

パスワードリセットリンクが有効な秒数。

PasswordResetConfirmView によって使用されます。

ノート

このタイムアウトの値を減らしても、攻撃者がパスワードリセットトークンをブルートフォースする能力に違いはありません。 トークンは、タイムアウトなしでブルートフォースから安全になるように設計されています。

このタイムアウトは、古い未使用のパスワードリセットトークンが含まれている可能性のある電子メールアーカイブに誰かがアクセスするなど、ありそうもない攻撃シナリオから保護するために存在します。


PASSWORD_RESET_TIMEOUT_DAYS

デフォルト：3

パスワードリセットリンクが有効な日数。

PasswordResetConfirmView によって使用されます。

バージョン3.1以降非推奨：この設定は非推奨です。 代わりに：setting： `PASSWORD_RESET_TIMEOUT` を使用してください。


PASSWORD_HASHERS

Djangoがパスワードを保存する方法を参照してください。

ディフォルト： 

[
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]

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 –は：setting： `SESSION_COOKIE_DOMAIN` 、：setting：` SESSION_COOKIE_SECURE` の値を使用します]および：setting： `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

ユーザーがブラウザを閉じたときにセッションを期限切れにするかどうか。 見るブラウザの長さのセッションと 永続的なセッション 。


SESSION_FILE_PATH

デフォルト：None

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


SESSION_SAVE_EVERY_REQUEST

デフォルト：False

リクエストごとにセッションデータを保存するかどうか。 これがFalse（デフォルト）の場合、セッションデータは、変更された場合、つまり、ディクショナリ値のいずれかが割り当てまたは削除された場合にのみ保存されます。 この設定がアクティブであっても、空のセッションは作成されません。


SESSION_SERIALIZER

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

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

  • 'django.contrib.sessions.serializers.PickleSerializer'
  • 'django.contrib.sessions.serializers.JSONSerializer'

PickleSerializer を使用した場合に実行される可能性のあるリモートコードに関する警告など、詳細については、セッションのシリアル化を参照してください。


サイト

django.contrib.sites の設定。

SITE_ID

デフォルト：未定義

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


静的ファイル

django.contrib.staticfiles の設定。

STATIC_ROOT

デフォルト：None

：djadmin： `collectstatic` が展開用の静的ファイルを収集するディレクトリへの絶対パス。

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

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

警告

これは、展開を容易にするために、静的ファイルを永続的な場所から1つのディレクトリに収集するための最初は空の宛先ディレクトリである必要があります。 静的ファイルを永続的に保存する場所ではありません。 あなたはによって見つけられるディレクトリでそれをするべきです staticfiles 'NS ：setting： `ファインダー ` 、デフォルトでは'static/'アプリのサブディレクトリとそれに含めるディレクトリ ：setting： `STATICFILES_DIRS` ）。


STATIC_URL

デフォルト：None

：setting： `STATIC_ROOT` にある静的ファイルを参照するときに使用するURL。

例："/static/"または"http://static.example.com/%22

Noneでない場合、これはアセット定義（Mediaクラス）および静的ファイルアプリのベースパスとして使用されます。

空でない値に設定されている場合は、スラッシュで終了する必要があります。

これらのファイルを開発で提供するように構成する必要がある場合があり、本番で確実に構成する必要があります。

ノート

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


STATICFILES_DIRS

デフォルト：[]（空のリスト）

この設定は、FileSystemFinderファインダーが有効になっている場合にstaticfilesアプリがトラバースする追加の場所を定義します。 ：djadmin： `collectstatic` または：djadmin：` 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"）。

プレフィックス（オプション）

追加の名前空間を持つ場所の1つにあるファイルを参照する場合は、オプションでプレフィックスを(prefix, path)タプルとして指定できます。例： 

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

たとえば、：setting： `STATIC_URL` が'/static/'に設定されているとすると、：djadmin：` collectstatic` 管理コマンドは次の「統計」ファイルを収集します。 ：setting： `STATIC_ROOT` の'downloads'サブディレクトリ。

これにより、テンプレートで'/static/downloads/polls_20101022.tar.gz'を使用してローカルファイル'/opt/webfiles/stats/polls_20101022.tar.gz'を参照できるようになります。例： 

<a href="{% static 'downloads/polls_20101022.tar.gz' %}">

STATICFILES_STORAGE

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

：djadmin： `collectstatic` 管理コマンドを使用して静的ファイルを収集するときに使用するファイルストレージエンジン。

この設定で定義されたストレージバックエンドのすぐに使用できるインスタンスは、django.contrib.staticfiles.storage.staticfiles_storageにあります。

例については、クラウドサービスまたはCDN からの静的ファイルの提供を参照してください。


STATICFILES_FINDERS

ディフォルト： 

[
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]

さまざまな場所で静的ファイルを見つける方法を知っているファインダーバックエンドのリスト。

デフォルトでは、：setting： `STATICFILES_DIRS` 設定（django.contrib.staticfiles.finders.FileSystemFinderを使用）および各アプリのstaticサブディレクトリ（django.contrib.staticfiles.finders.AppDirectoriesFinderを使用）に保存されているファイルが検索されます。 ]）。 同じ名前のファイルが複数存在する場合は、最初に見つかったファイルが使用されます。

1つのファインダーはデフォルトで無効になっています：django.contrib.staticfiles.finders.DefaultStorageFinder。 ：setting： `STATICFILES_FINDERS` 設定に追加すると、：setting：` DEFAULT_FILE_STORAGE` 設定で定義されているデフォルトのファイルストレージで静的ファイルが検索されます。

ノート

AppDirectoriesFinderファインダーを使用する場合は、サイトの：setting： `INSTALLED_APPS` 設定にアプリを追加して、静的ファイルでアプリが見つかることを確認してください。


静的ファイルファインダーは現在プライベートインターフェイスと見なされているため、このインターフェイスは文書化されていません。


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

テンプレート



「https://www.finddevguides.com/index.php?title=Django/docs/3.2.x/ref/settings&oldid=96245」から取得
Powered by MediaWiki