設定¶

ABSOLUTE_URL_OVERRIDES¶

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

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

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

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

ADMINS¶

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

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

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

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

ALLOWED_HOSTS¶

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

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

このリスト中の値は完全修飾名 (fully qualified names) (例: 'www.example.com') でも大丈夫です。その場合には、リクエストの Host ヘッダに完全一致するかチェックされます (ポートを含まない、大文字小文字を無視した比較になります)。ピリオドで始まる値は、サブドメインのワイルドカードとして利用できます。たとえば、'.example.com' は example.com や www.example.com などの他のすべての example.com サブドメインにマッチします。'*' という値はあらゆるヘッダにマッチします。この場合には、責任を持って自前の Host ヘッダ検証機 (おそらくミドルウェアの形になり、その場合は MIDDLEWARE 設定の最初に置く必要があります) を書かなければなりません。

Django はあらゆるエントリで fully qualified domain name (FQDN) を許可しています。ブラウザの中には Host ヘッダの最後にドットを付けるもありますが、Django は host の検証機でそれを取り除きます。

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

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

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

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

APPEND_SLASH¶

デフォルト値: True

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

APPEND_SLASH 設定は CommonMiddleware がインストールされているときのみ有効です。詳しくは see ミドルウェア (Middleware) を参照。また PREPEND_WWW も参照してください。

CACHES¶

デフォルト値:

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

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

CACHES 設定では、default キャッシュを設定する必要があります。追加で任意の数のキャッシュを指定することもできます。ローカルメモリキャッシュ以外のキャッシュバックエンドを使用する場合、または複数のキャッシュを定義する必要がある場合は、他のオプションが必要になります。以下のキャッシュオプションが利用可能です。

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

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

CACHE_MIDDLEWARE_ALIAS¶

デフォルト値: 'default'

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

CACHE_MIDDLEWARE_KEY_PREFIX¶

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

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

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

CACHE_MIDDLEWARE_SECONDS¶

デフォルト値: 600

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

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

CSRF_COOKIE_AGE¶

デフォルト値: 31449600 (約1年、秒単位)

CSRF クッキーの有効期間 (秒単位)。

長期間の有効期限を設定する理由は、ユーザーがブラウザを閉じたり、ページをブックマークして、後でそのページをブラウザのキャッシュから読み込む場合の問題を避けるためです。永続的なクッキーがなければ、この場合にフォームの送信は失敗するでしょう。

一部のブラウザ（特にInternet Explorer）では、永続的なクッキーの使用を禁止したり、クッキージャーのインデックスがディスク上で破損して、CSRF保護チェックが（時々断続的に）失敗する原因となることがあります。この設定を None に変更すると、クッキーを永続的なストレージではなくメモリ内に保持するセッションベースのCSRFクッキーを使用します。

CSRF_COOKIE_DOMAIN¶

デフォルト値: None

CSRFクッキーを設定する際に使用されるドメインです。通常のクロスサイトリクエストフォージェリ保護から除外されるクロスサブドメインリクエストを簡単に許可するのに役立ちます。フォームからのPOSTリクエストが別のサブドメインから提供されるビューで受け入れられるようにするには、 ".example.com" のような文字列で設定する必要があります。

この設定が存在することは、デフォルトで Django の CSRF 保護が、クロスサブドメイン攻撃から安全であることを意味するものではありません。詳細については、 CSRF の制限 セクションを参照してください。

CSRF_COOKIE_HTTPONLY¶

デフォルト値: False

CSRFクッキーに HttpOnly フラグを使用するかどうか。これが True に設定されている場合、クライアントサイドのJavaScriptはCSRFクッキーにアクセスできません。

CSRFクッキーを HttpOnly として指定しても、実際のところ保護にはなりません。なぜなら、CSRFはクロスドメイン攻撃を防ぐためだけに存在するからです。攻撃者がJavaScript経由でクッキーを読み取ることができる場合、ブラウザが知っている限りでは既に同一ドメイン上にいるので、何でも好きなことを行うことができます。(XSSはCSRFよりもずっと大きな脅威です。)

この設定が実際に大きな利益を提供することは少ないですが、セキュリティ監査員によっては必要とされることがあります。

これを有効にし、AJAXリクエストでCSRFトークンの値を送信する必要がある場合、JavaScriptは クッキーから ではなく、 隠されたCSRFトークンのフォーム入力から 値を取得する必要があります。

HttpOnly の詳細については、SESSION_COOKIE_HTTPONLY を参照してください。

CSRF_COOKIE_NAME¶

デフォルト値: 'csrftoken'

CSRF 認証トークンに使用するクッキーの名前。他のクッキー名と異なる限り、任意の名前を使用できます。詳細は、 クロスサイトリクエストフォージェリ (CSRF) 対策 を参照してください。

CSRF_COOKIE_PATH¶

デフォルト値: '/'

CSRFクッキーに設定されたパス。これは、DjangoインストールのURLパスと一致するか、そのパスの親である必要があります。

複数の Django インスタンスを同じホスト名で実行している場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身の CSRF クッキーのみを確認できます。

CSRF_COOKIE_SAMESITE¶

デフォルト値: 'Lax'

CSRFクッキーの SameSite フラグの値です。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎます。

SameSite についての詳細は、SESSION_COOKIE_SAMESITE を参照してください。

CSRF_COOKIE_SECURE¶

デフォルト値: False

CSRF（Cross-Site Request Forgery）クッキーにセキュアクッキーを使用するかどうかを指定します。これを True に設定すると、そのクッキーは「セキュア」としてマークされ、ブラウザはそのクッキーがHTTPS接続でのみ送信されることを確認できます。

CSRF_USE_SESSIONS¶

デフォルト値: False

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

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

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

CSRF_FAILURE_VIEW¶

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

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

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

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

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

CSRF_HEADER_NAME¶

デフォルト値: 'HTTP_X_CSRFTOKEN'

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

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

CSRF_TRUSTED_ORIGINS¶

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

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

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

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

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

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

DATABASES¶

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

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

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

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

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

MariaDB、MySQL、Oracle、または PostgreSQL などの他のデータベースバックエンドに接続する場合、追加の接続パラメータが必要になります。他のデータベースタイプを指定する方法については、以下の ENGINE 設定を参照してください。この例は PostgreSQL 用です:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "mydatabase",
        "USER": "mydatabaseuser",
        "PASSWORD": "mypassword",
        "HOST": "127.0.0.1",
        "PORT": "5432",
    }
}

より複雑な設定に必要な次の内部オプションが利用可能です:

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

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

DATA_UPLOAD_MAX_MEMORY_SIZE¶

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

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

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

関連項目: FILE_UPLOAD_MAX_MEMORY_SIZE

DATA_UPLOAD_MAX_NUMBER_FIELDS¶

デフォルト値: 1000

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

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

DATA_UPLOAD_MAX_NUMBER_FILES¶

デフォルト値: 100

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

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

DATABASE_ROUTERS¶

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

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

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

DATE_FORMAT¶

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

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

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

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

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

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

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

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

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

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

DEBUG_PROPAGATE_EXCEPTIONS¶

デフォルト値: False

True に設定されている場合、Djangoのビュー関数の例外処理 (handler500 、または DEBUG が True の場合はデバッグビュー) と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 の属性がないモデルに使用するデフォルトの主キーのフィールドタイプ。

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'

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

DEFAULT_FROM_EMAIL¶

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

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

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

DEFAULT_INDEX_TABLESPACE¶

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

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

DEFAULT_TABLESPACE¶

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

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

DISALLOWED_USER_AGENTS¶

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

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

EMAIL_BACKEND¶

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

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

EMAIL_FILE_PATH¶

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

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

EMAIL_HOST¶

デフォルト値: 'localhost'

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

EMAIL_PORT も参照してください。

EMAIL_HOST_PASSWORD¶

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

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

EMAIL_HOST_USER も参照してください。

EMAIL_HOST_USER¶

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

EMAIL_HOST 内で定義された SMTP サーバで使われるユーザ名です。空の場合、Django は認証を試みません。

EMAIL_HOST_PASSWORD も参照してください。

EMAIL_PORT¶

デフォルト値: 25

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

EMAIL_SUBJECT_PREFIX¶

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

django.core.mail.mail_admins や django.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_TLS が True の場合、オプションで、SSL 接続用に使う PEM フォーマットの証明書チェーンファイルを指定できます。

EMAIL_SSL_KEYFILE¶

デフォルト値: None

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

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

EMAIL_TIMEOUT¶

デフォルト値: None

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

FILE_UPLOAD_HANDLERS¶

デフォルト値:

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

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

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

FILE_UPLOAD_MAX_MEMORY_SIZE¶

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

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

関連項目: DATA_UPLOAD_MAX_MEMORY_SIZE

FILE_UPLOAD_DIRECTORY_PERMISSIONS¶

デフォルト値: None

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

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

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

FILE_UPLOAD_PERMISSIONS¶

デフォルト値: 0o644

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

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

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

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

FILE_UPLOAD_TEMP_DIR¶

デフォルト値: None

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

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

FIRST_DAY_OF_WEEK¶

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

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

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

FIXTURE_DIRS¶

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

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

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

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

FORCE_SCRIPT_NAME¶

デフォルト値: None

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

FORM_RENDERER¶

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

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

• 'django.forms.renderers.DjangoTemplates'
• 'django.forms.renderers.Jinja2'
• 'django.forms.renderers.TemplatesSetting'

FORMS_URLFIELD_ASSUME_HTTPS¶

デフォルト値: False

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

FORMAT_MODULE_PATH¶

デフォルト値: None

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

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

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

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

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

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

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

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

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT,
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• YEAR_MONTH_FORMAT

IGNORABLE_404_URLS¶

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

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

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

INSTALLED_APPS¶

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

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

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

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

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

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 はどうやって言語の優先順位を検出するのか？ を参照してください。

LANGUAGE_COOKIE_AGE¶

デフォルト値: None (ブラウザを閉じると期限切れとなります)

言語クッキーの age で、秒で表します。

LANGUAGE_COOKIE_DOMAIN¶

デフォルト値: None

言語クッキーに使用するドメインです。クロスドメインのクッキーのために "example.com" のような文字列に設定するか、標準のドメインクッキーには None を使用します。

本番サイトでこの設定を更新する際には注意してください。これまで標準ドメインのクッキーを使用していたサイトでこの設定を更新してクロスドメインのクッキーを有効にすると、古いドメインの既存のユーザークッキーは更新されません。これにより、これらのクッキーが残存している限り、サイトのユーザーは言語を切り替えることができなくなります。スイッチを行う唯一の安全で確実なオプションは、言語クッキーの名前を ( LANGUAGE_COOKIE_NAME 設定により) 恒久的に変更し、古いクッキーから新しいクッキーへ値をコピーし、古いものを削除するミドルウェアを追加することです。

LANGUAGE_COOKIE_HTTPONLY¶

デフォルト値: False

言語クッキーに HttpOnly フラグを使用するかどうか。これが True に設定されている場合、クライアントサイドの JavaScript は言語クッキーにアクセスできません。

HttpOnly の詳細については、SESSION_COOKIE_HTTPONLY を参照してください。

LANGUAGE_COOKIE_NAME¶

デフォルト値: 'django_language'

言語クッキーに使用するクッキーの名前です。これはあなたが望むものであれば何でも構いません（ただし、アプリケーション内の他のクッキー名と異なる必要があります）。詳細は 国際化とローカライズ を参照してください。

LANGUAGE_COOKIE_PATH¶

デフォルト値: '/'

言語クッキーのパス。これは、Django のインストール先の URL パスと一致するか、そのパスの親である必要があります。

これは、同じホスト名の下で複数の Django インスタンスが実行されている場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身の言語クッキーのみを確認できます。

本番サイトでこの設定を更新する際には慎重に行ってください。もし、この設定で以前よりも深いパスを使用するように更新した場合、古いパスを持つ既存のユーザークッキーは更新されません。これにより、これらのクッキーが存在する限り、サイトのユーザーは言語を切り替えることができなくなります。切り替えを安全かつ確実に行う唯一の方法は、言語クッキーの名前を永続的に変更すること (LANGUAGE_COOKIE_NAME 設定を通じて)、そして古いクッキーから新しいクッキーへ値をコピーしてから古いクッキーを削除するミドルウェアを追加することです。

LANGUAGE_COOKIE_SAMESITE¶

デフォルト値: None

言語クッキーの SameSite フラグの値です。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎます。

SameSite についての詳細は、SESSION_COOKIE_SAMESITE を参照してください。

LANGUAGE_COOKIE_SECURE¶

デフォルト値: False

言語クッキーにセキュアクッキーを使用するかどうか。これが True に設定されている場合、クッキーは "secure" としてマークされ、ブラウザーはそのクッキーが HTTPS 接続下でのみ送信されることを保証する場合があります。

LANGUAGES¶

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

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

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

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

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

from django.utils.translation import gettext_lazy as _

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

LANGUAGES_BIDI¶

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

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

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

LOCALE_PATHS¶

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

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

実装例:

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

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

LOGGING¶

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

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

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

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

LOGGING_CONFIG¶

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

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

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

MANAGERS¶

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

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

MEDIA_ROOT¶

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

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

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

関連項目: MEDIA_URL

MEDIA_URL¶

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

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

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

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

MIDDLEWARE¶

デフォルト値: None

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

MIGRATION_MODULES¶

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

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

実装例:

{"blog": "blog.db_migrations"}

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

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

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

MONTH_DAY_FORMAT¶

デフォルト値: 'F j'

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

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

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

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

NUMBER_GROUPING¶

デフォルト値: 0

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

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

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

en_IN のための例のタプル:

NUMBER_GROUPING = (3, 2, 0)

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

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

PREPEND_WWW¶

デフォルト値: False

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

ROOT_URLCONF¶

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

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

SECRET_KEY¶

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

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

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

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

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

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

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

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

SECRET_KEY_FALLBACKS¶

デフォルト値: []

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

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

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

SECURE_CONTENT_TYPE_NOSNIFF¶

デフォルト値: True

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

SECURE_CROSS_ORIGIN_OPENER_POLICY¶

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

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

SECURE_HSTS_INCLUDE_SUBDOMAINS¶

デフォルト値: False

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

SECURE_HSTS_PRELOAD¶

デフォルト値: False

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

SECURE_HSTS_SECONDS¶

デフォルト値: 0

ゼロでない整数値に設定されている場合、 SecurityMiddleware は、まだ設定されていないすべてのレスポンスに対して 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 で利用可能にします。)

SECURE_REDIRECT_EXEMPT¶

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

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

SECURE_REFERRER_POLICY¶

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

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

SECURE_SSL_HOST¶

デフォルト値: None

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

SECURE_SSL_REDIRECT¶

デフォルト値: False

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

SERIALIZATION_MODULES¶

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

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

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

SERVER_EMAIL¶

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

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

SHORT_DATE_FORMAT¶

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

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

関連項目: DATE_FORMAT, SHORT_DATETIME_FORMAT

SHORT_DATETIME_FORMAT¶

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

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

関連項目: DATE_FORMAT, SHORT_DATE_FORMAT

SIGNING_BACKEND¶

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

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

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

SILENCED_SYSTEM_CHECKS¶

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

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

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

STORAGES¶

デフォルト値:

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

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

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

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

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

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

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

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

TEMPLATES¶

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

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

以下の設定では、Django テンプレートエンジンに対し、インストールされた各アプリケーション内の templates サブディレクトリからテンプレートを読み込むよう指示します:

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

すべてのバックエンドで利用可能なオプションは以下の通りです:

TEST_RUNNER¶

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

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

TEST_NON_SERIALIZED_APPS¶

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

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

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

THOUSAND_SEPARATOR¶

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

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

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

関連項目: 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 を参照してください。

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

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

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

USE_I18N¶

デフォルト値: True

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

関連項目: LANGUAGE_CODE および USE_TZ

USE_THOUSAND_SEPARATOR¶

デフォルト値: False

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

関連項目: DECIMAL_SEPARATOR, NUMBER_GROUPING, THOUSAND_SEPARATOR

USE_TZ¶

デフォルト値: True

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

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

関連項目:TIME_ZONE および USE_I18N

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_FORMAT 、 DATETIME_FORMAT 、 TIME_FORMAT および MONTH_DAY_FORMAT も参照してください。

X_FRAME_OPTIONS¶

デフォルト値: 'DENY'

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

AUTHENTICATION_BACKENDS¶

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

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

AUTH_USER_MODEL¶

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

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

LOGIN_REDIRECT_URL¶

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

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

LOGIN_URL¶

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

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

LOGOUT_REDIRECT_URL¶

デフォルト値: None

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

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

PASSWORD_RESET_TIMEOUT¶

デフォルト値: 259200 (秒単位で、3日)

パスワードリセットリンクの有効期間 (秒単位)。

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

PASSWORD_HASHERS¶

関連項目: Djangoのパスワード保存方法

デフォルト値:

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

AUTH_PASSWORD_VALIDATORS¶

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

ユーザーのパスワードの強度をチェックするために使用されるバリデータのリストです。詳細については パスワードの妥当性検証 を参照してください。デフォルトでは、バリデーションは実行されず、すべてのパスワードが受け入れられます。

MESSAGE_LEVEL¶

デフォルト値: messages.INFO

メッセージフレームワークによって記録されるメッセージレベルの最小値を設定します。 詳細については、 メッセージレベル を参照してください。

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クラスとしてレンダリングされるメッセージタグのマッピングを設定します。値を指定すると、デフォルトを拡張します。つまり、オーバーライドする必要がある値のみを指定すればよいことを意味します。詳細については、上記の メッセージを表示する を参照してください。

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

SESSION_CACHE_ALIAS¶

デフォルト値: 'default'

キャッシュベースのセッションストレージ を使用している場合、これによって使用するキャッシュが選択されます。

SESSION_COOKIE_AGE¶

デフォルト値: 1209600 (2 週間の秒表記)

セッションクッキーの寿命 (秒単位)。

SESSION_COOKIE_DOMAIN¶

デフォルト値: None

セッションクッキーに使用するドメインです。クロスドメインクッキーの場合は "example.com" のような文字列に設定するか、標準ドメインクッキーには None を使用してください。

CSRF_USE_SESSIONS を使用してクロスドメインのクッキーを使用する場合、CSRFミドルウェアのリファラチェックを受け入れるために、先頭にドット (例: ".example.com") を含めなければなりません。

本番サイトでこの設定を更新する場合は慎重に行ってください。以前は標準ドメインのクッキーを使用していたサイトでこの設定を更新してクロスドメインのクッキーを有効にした場合、既存のユーザークッキーは古いドメインに設定されます。これにより、これらのクッキーが存在する限り、ログインできなくなる可能性があります。

この設定は、 django.contrib.messages によって設定されるクッキーにも影響します。

SESSION_COOKIE_HTTPONLY¶

デフォルト値: True

セッションクッキーに HttpOnly フラグを使用するかどうか。これが True に設定されている場合、クライアント側の JavaScript はセッションクッキーにアクセスできません。

HttpOnly は Set-Cookie HTTPレスポンスヘッダーに含まれるフラグです。クッキーのための RFC 6265#section-4.1.2.6 標準の一部であり、クライアントサイドのスクリプトが保護されたクッキーデータにアクセスするリスクを軽減する有用な方法です。

これにより、攻撃者がクロスサイトスクリプティングの脆弱性を利用してユーザーのセッションを完全に乗っ取ることが困難になります。これをオフにする正当な理由はほとんどありません。コードは JavaScript からセッションクッキーを読み取るべきではありません。

SESSION_COOKIE_NAME¶

デフォルト値: 'sessionid'

セッションに使用するクッキーの名前です。これはあなたが望むものであれば何でも構いません（ただし、アプリケーション内の他のクッキー名と異なる必要があります）。

SESSION_COOKIE_PATH¶

デフォルト値: '/'

セッションクッキーに設定されたパス。これは、DjangoインストールのURLパスと一致するか、そのパスの親であるべきです。

これは、同じホスト名の下で複数の Django インスタンスが実行されている場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身のセッションクッキーのみを確認できます。

SESSION_COOKIE_SAMESITE¶

デフォルト値: 'Lax'

セッションクッキーの SameSite フラグの値。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎ、CSRF攻撃を防ぎ、セッションクッキーを盗むいくつかの方法を不可能にします。

設定で指定できる値は次のとおりです:

• 'Strict': ブラウザが全てのクロスサイトブラウジングコンテキストにおいて、通常のリンクをたどる場合であっても、ターゲットサイトへクッキーを送信することを防ぎます。

  例えば、GitHubのようなウェブサイトでは、ログインしたユーザーが企業のディスカッションフォーラムやメールに掲載された非公開のGitHubプロジェクトへのリンクをたどる場合、GitHubはセッションクッキーを受け取らず、ユーザーはそのプロジェクトにアクセスできなくなります。一方、銀行のウェブサイトでは、おそらく外部サイトからの取引ページへのリンクを許可したくないため、 'Strict' フラグが適切でしょう。

• 'Lax' (デフォルト): 外部リンクからユーザーが訪れた後でも、ユーザーのログイン状態を維持したいウェブサイトに対して、セキュリティと利便性のバランスを提供します。

  GitHub のシナリオでは、外部ウェブサイトから通常のリンクをたどる際にはセッションクッキーが許可され、CSRFに対して脆弱なリクエストメソッド (例: POST) ではブロックされます。

• 'None' (文字列): セッションクッキーは、同一サイトおよびクロスサイトの全てのリクエストに対して送信されます。

• False: フラグを無効にします。

SESSION_COOKIE_SECURE¶

デフォルト値: False

セッションクッキーにセキュアクッキーを使用するかどうかです。これが True に設定されている場合、クッキーは「セキュア」にマークされ、ブラウザはそのクッキーが HTTPS 接続下でのみ送信されることを保証するかもしれません。

この設定をオフにしておくことは良いアイデアではありません。なぜなら、攻撃者がパケットスニファーで暗号化されていないセッションクッキーをキャプチャし、そのクッキーを使用してユーザーのセッションを乗っ取る可能性があるからです。

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'

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

SITE_ID¶

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

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

STATIC_ROOT¶

デフォルト値: None

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

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

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

STATIC_URL¶

デフォルト値: None

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

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

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

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

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

STATICFILES_DIRS¶

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

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

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

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

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

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

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

STATICFILES_STORAGE¶

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

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

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

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

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 キーで定義されたデフォルトファイルストレージ内の静的ファイルを探します。

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

キャッシュ¶

• CACHES
• CACHE_MIDDLEWARE_ALIAS
• CACHE_MIDDLEWARE_KEY_PREFIX
• CACHE_MIDDLEWARE_SECONDS

データベース¶

• DATABASES
• DATABASE_ROUTERS
• DEFAULT_INDEX_TABLESPACE
• DEFAULT_TABLESPACE

デバッグ¶

• DEBUG
• DEBUG_PROPAGATE_EXCEPTIONS

Eメール¶

• ADMINS
• DEFAULT_CHARSET
• DEFAULT_FROM_EMAIL
• EMAIL_BACKEND
• EMAIL_FILE_PATH
• EMAIL_HOST
• EMAIL_HOST_PASSWORD
• EMAIL_HOST_USER
• EMAIL_PORT
• EMAIL_SSL_CERTFILE
• EMAIL_SSL_KEYFILE
• EMAIL_SUBJECT_PREFIX
• EMAIL_TIMEOUT
• EMAIL_USE_LOCALTIME
• EMAIL_USE_TLS
• MANAGERS
• SERVER_EMAIL

エラーのレポート¶

• DEFAULT_EXCEPTION_REPORTER
• DEFAULT_EXCEPTION_REPORTER_FILTER
• IGNORABLE_404_URLS
• MANAGERS
• SILENCED_SYSTEM_CHECKS

ファイルアップロード¶

• DEFAULT_FILE_STORAGE
• FILE_UPLOAD_HANDLERS
• FILE_UPLOAD_MAX_MEMORY_SIZE
• FILE_UPLOAD_PERMISSIONS
• FILE_UPLOAD_TEMP_DIR
• MEDIA_ROOT
• MEDIA_URL
• STORAGES

フォーム¶

• FORM_RENDERER
• FORMS_URLFIELD_ASSUME_HTTPS

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

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• FORMAT_MODULE_PATH
• LANGUAGE_CODE
• LANGUAGE_COOKIE_AGE
• LANGUAGE_COOKIE_DOMAIN
• LANGUAGE_COOKIE_HTTPONLY
• LANGUAGE_COOKIE_NAME
• LANGUAGE_COOKIE_PATH
• LANGUAGE_COOKIE_SAMESITE
• LANGUAGE_COOKIE_SECURE
• LANGUAGES
• LANGUAGES_BIDI
• LOCALE_PATHS
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• TIME_ZONE
• USE_I18N
• USE_THOUSAND_SEPARATOR
• USE_TZ
• YEAR_MONTH_FORMAT

HTTP¶

• DATA_UPLOAD_MAX_MEMORY_SIZE
• DATA_UPLOAD_MAX_NUMBER_FIELDS
• DATA_UPLOAD_MAX_NUMBER_FILES
• DEFAULT_CHARSET
• DISALLOWED_USER_AGENTS
• FORCE_SCRIPT_NAME
• INTERNAL_IPS
• MIDDLEWARE
• セキュリティ
  • SECURE_CONTENT_TYPE_NOSNIFF
  • SECURE_CROSS_ORIGIN_OPENER_POLICY
  • SECURE_HSTS_INCLUDE_SUBDOMAINS
  • SECURE_HSTS_PRELOAD
  • SECURE_HSTS_SECONDS
  • SECURE_PROXY_SSL_HEADER
  • SECURE_REDIRECT_EXEMPT
  • SECURE_REFERRER_POLICY
  • SECURE_SSL_HOST
  • SECURE_SSL_REDIRECT
• SIGNING_BACKEND
• USE_X_FORWARDED_HOST
• USE_X_FORWARDED_PORT
• WSGI_APPLICATION

ロギング¶

• LOGGING
• LOGGING_CONFIG

モデル¶

• ABSOLUTE_URL_OVERRIDES
• FIXTURE_DIRS
• INSTALLED_APPS

セキュリティ¶

• クロスサイトリクエストフォージェリ (CSRF) 保護
  • CSRF_COOKIE_DOMAIN
  • CSRF_COOKIE_NAME
  • CSRF_COOKIE_PATH
  • CSRF_COOKIE_SAMESITE
  • CSRF_COOKIE_SECURE
  • CSRF_FAILURE_VIEW
  • CSRF_HEADER_NAME
  • CSRF_TRUSTED_ORIGINS
  • CSRF_USE_SESSIONS
• SECRET_KEY
• SECRET_KEY_FALLBACKS
• X_FRAME_OPTIONS

シリアライズ¶

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

テンプレート¶

• TEMPLATES

テスト¶

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

URL¶

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF