--- title: "設定" version: 3.2 locale: ja source: https://docs.djangoproject.com/ja/3.2/ref/settings/ canonical: https://djangodocs.dev/ja/3.2/ref/settings/ --- # 設定 - [コアの設定](#core-settings) - [Auth](#auth) - [メッセージ](#messages) - [セッション](#sessions) - [サイト](#sites) - [静的ファイル](#static-files) - [Core Settings Topical Index](#core-settings-topical-index) > **Warning** > > Be careful when you override settings, especially when the default value > is a non-empty list or dictionary, such as [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS). > Make sure you keep the components required by the features of Django you > wish to use. ## コアの設定 ここでは、Django の core で利用できる設定とそのデフォルト値をリストしました。contrib アプリで提供される設定のリストは、core の設定のトピックのインデックスの下にあります。入門的な資料については、 [settings topic guide](/ja/3.2/topics/settings/) をご覧ください。 ### `ABSOLUTE_URL_OVERRIDES` デフォルト値: `{}` (空の辞書) A dictionary mapping `"app_label.model_name"` strings to functions that take a model object and return its URL. This is a way of inserting or overriding `get_absolute_url()` methods on a per-installation basis. Example: ``` ABSOLUTE_URL_OVERRIDES = { 'blogs.weblog': lambda o: "/blogs/%s/" % o.slug, 'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), } ``` The model name used in this setting should be all lowercase, regardless of the case of the actual model class name. ### `ADMINS` デフォルト値: `[]` (空のリスト) A list of all the people who get code error notifications. When [`DEBUG=False`](#std-setting-DEBUG) and [`AdminEmailHandler`](/ja/3.2/topics/logging/#django.utils.log.AdminEmailHandler) is configured in [`LOGGING`](#std-setting-LOGGING) (done by default), Django emails these people the details of exceptions raised in the request/response cycle. Each item in the list should be a tuple of (Full name, email address). Example: ``` [('John', 'john@example.com'), ('Mary', 'mary@example.com')] ``` ### `ALLOWED_HOSTS` デフォルト値: `[]` (空のリスト) Django サイトを配信できるホスト/ドメイン名を表す文字列のリストです。これはセキュリティ対策の手段の1つで、一見安全な設定の Web サーバでも晒される可能性が高い、 [HTTP Host header 攻撃](/ja/3.2/topics/security/#host-headers-virtual-hosting) を防ぐことができます。 このリスト中の値は完全修飾名 (fully qualified names) (例: `'www.example.com'`) でも大丈夫です。その場合には、リクエストの `Host` ヘッダに完全一致するかチェックされます (ポートを含まない、大文字小文字を無視した比較になります)。ピリオドで始まる値は、サブドメインのワイルドカードとして利用できます。たとえば、`'.example.com'` は `example.com` や `www.example.com` などの他のすべての `example.com` サブドメインにマッチします。`'*'` という値はあらゆるヘッダにマッチします。この場合には、責任を持って自前の `Host` ヘッダ検証機 (おそらくミドルウェアの形になり、その場合は [`MIDDLEWARE`](#std-setting-MIDDLEWARE) 設定の最初に置く必要があります) を書かなければなりません。 Django はあらゆるエントリで [fully qualified domain name (FQDN)](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) を許可しています。ブラウザの中には\`\`Host\`\` ヘッダの最後にドットを付けるもありますが、Django は host の検証機でそれを取り除きます。 `Host` ヘッダ (と [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) が有効な場合は `X-Forwarded-Host`) が、このリストのどれとも一致しない場合、 [`django.http.HttpRequest.get_host()`](/ja/3.2/ref/request-response/#django.http.HttpRequest.get_host) は [`SuspiciousOperation`](/ja/3.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) 例外を起こします。 When [`DEBUG`](#std-setting-DEBUG) is `True` and `ALLOWED_HOSTS` is empty, the host is validated against `['.localhost', '127.0.0.1', '[::1]']`. `ALLOWED_HOSTS` is also [checked when running tests](/ja/3.2/topics/testing/advanced/#topics-testing-advanced-multiple-hosts). このヘッダの検証は [`get_host()`](/ja/3.2/ref/request-response/#django.http.HttpRequest.get_host) メソッドの実行時にのみ適用されます。もし `request.META` から直接 `Host` ヘッダにアクセスするコードを書いてしまうと、このセキュリティプロテクションを回避してしまうので注意してください。 > **Changed in Django 3.1** > > If `ALLOWED_HOSTS` is empty and `DEBUG=True`, subdomains of localhost > were allowed. ### `APPEND_SLASH` デフォルト値: `True` `True` に設定すると、リクエスト URL が URLconf 内のどのパターンにもマッチせず、/ で終わっていなかった場合に、末尾に / を追加した URL への HTTP リダイレクトを発行します。ただし、リダイレクトすると POST リクエストで送信するデータが失われることがあるので注意が必要です。 [`APPEND_SLASH`](#std-setting-APPEND_SLASH) 設定は [`CommonMiddleware`](/ja/3.2/ref/middleware/#django.middleware.common.CommonMiddleware) がインストールされているときのみ有効です。詳しくは see [ミドルウェア (Middleware)](/ja/3.2/topics/http/middleware/) を参照。また [`PREPEND_WWW`](#std-setting-PREPEND_WWW) もお読みください。 ### `CACHES` デフォルト値: ``` { 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', } } ``` A dictionary containing the settings for all caches to be used with Django. It is a nested dictionary whose contents maps cache aliases to a dictionary containing the options for an individual cache. The [`CACHES`](#std-setting-CACHES) setting must configure a `default` cache; any number of additional caches may also be specified. If you are using a cache backend other than the local memory cache, or you need to define multiple caches, other options will be required. The following cache options are available. #### `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 に同梱されていないキャッシュ用バックエンドを使用する時は、[`BACKEND`](#std-setting-CACHES-BACKEND) にバックエンドのクラスの完全修飾パス (例: `mypackage.backends.whatever.WhateverCache`) を設定してください。 > **Changed in Django 3.2** > > The `PyMemcacheCache` backend was added. #### `KEY_FUNCTION` A string containing a dotted path to a function (or any callable) that defines how to compose a prefix, version and key into a final cache key. The default implementation is equivalent to the function: ``` def make_key(key, key_prefix, version): return ':'.join([key_prefix, str(version), key]) ``` You may use any key function you want, as long as it has the same argument signature. See the [cache documentation](/ja/3.2/topics/cache/#cache-key-transformation) for more information. #### `KEY_PREFIX` デフォルト値: `''` (空文字列) A string that will be automatically included (prepended by default) to all cache keys used by the Django server. See the [cache documentation](/ja/3.2/topics/cache/#cache-key-prefixing) for more information. #### `LOCATION` デフォルト値: `''` (空文字列) The location of the cache to use. This might be the directory for a file system cache, a host and port for a memcache server, or an identifying name for a local memory cache. e.g.: ``` CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache', 'LOCATION': '/var/tmp/django_cache', } } ``` #### `OPTIONS` デフォルト値: `None` Extra parameters to pass to the cache backend. Available parameters vary depending on your cache backend. Some information on available parameters can be found in the [cache arguments](/ja/3.2/topics/cache/#cache-arguments) documentation. For more information, consult your backend module's own documentation. #### `TIMEOUT` デフォルト値: `300` The number of seconds before a cache entry is considered stale. If the value of this settings is `None`, cache entries will not expire. #### `VERSION` デフォルト値: `1` The default version number for cache keys generated by the Django server. See the [cache documentation](/ja/3.2/topics/cache/#cache-versioning) for more information. ### `CACHE_MIDDLEWARE_ALIAS` デフォルト値: `'default'` The cache connection to use for the [cache middleware](/ja/3.2/topics/cache/#the-per-site-cache). ### `CACHE_MIDDLEWARE_KEY_PREFIX` デフォルト値: `''` (空文字列) A string which will be prefixed to the cache keys generated by the [cache middleware](/ja/3.2/topics/cache/#the-per-site-cache). This prefix is combined with the [`KEY_PREFIX`](#std-setting-CACHES-KEY_PREFIX) setting; it does not replace it. See [Django's cache framework](/ja/3.2/topics/cache/). ### `CACHE_MIDDLEWARE_SECONDS` デフォルト値: `600` The default number of seconds to cache a page for the [cache middleware](/ja/3.2/topics/cache/#the-per-site-cache). See [Django's cache framework](/ja/3.2/topics/cache/). ### `CSRF_COOKIE_AGE` Default: `31449600` (approximately 1 year, in seconds) The age of CSRF cookies, in seconds. The reason for setting a long-lived expiration time is to avoid problems in the case of a user closing a browser or bookmarking a page and then loading that page from a browser cache. Without persistent cookies, the form submission would fail in this case. Some browsers (specifically Internet Explorer) can disallow the use of persistent cookies or can have the indexes to the cookie jar corrupted on disk, thereby causing CSRF protection checks to (sometimes intermittently) fail. Change this setting to `None` to use session-based CSRF cookies, which keep the cookies in-memory instead of on persistent storage. ### `CSRF_COOKIE_DOMAIN` デフォルト値: `None` The domain to be used when setting the CSRF cookie. This can be useful for easily allowing cross-subdomain requests to be excluded from the normal cross site request forgery protection. It should be set to a string such as `".example.com"` to allow a POST request from a form on one subdomain to be accepted by a view served from another subdomain. Please note that the presence of this setting does not imply that Django's CSRF protection is safe from cross-subdomain attacks by default - please see the [CSRF limitations](/ja/3.2/ref/csrf/#csrf-limitations) section. ### `CSRF_COOKIE_HTTPONLY` デフォルト値: `False` Whether to use `HttpOnly` flag on the CSRF cookie. If this is set to `True`, client-side JavaScript will not be able to access the CSRF cookie. Designating the CSRF cookie as `HttpOnly` doesn't offer any practical protection because CSRF is only to protect against cross-domain attacks. If an attacker can read the cookie via JavaScript, they're already on the same domain as far as the browser knows, so they can do anything they like anyway. (XSS is a much bigger hole than CSRF.) Although the setting offers little practical benefit, it's sometimes required by security auditors. If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value [from a hidden CSRF token form input](/ja/3.2/ref/csrf/#acquiring-csrf-token-from-html) instead of [from the cookie](/ja/3.2/ref/csrf/#acquiring-csrf-token-from-cookie). See [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) for details on `HttpOnly`. ### `CSRF_COOKIE_NAME` デフォルト値: `'csrftoken'` The name of the cookie to use for the CSRF authentication token. This can be whatever you want (as long as it's different from the other cookie names in your application). See [クロスサイトリクエストフォージェリ (CSRF) 対策](/ja/3.2/ref/csrf/). ### `CSRF_COOKIE_PATH` デフォルト値: `'/'` The path set on the CSRF cookie. This should either match the URL path of your Django installation or be a parent of that path. This is useful if you have multiple Django instances running under the same hostname. They can use different cookie paths, and each instance will only see its own CSRF cookie. ### `CSRF_COOKIE_SAMESITE` Default: `'Lax'` The value of the [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) flag on the CSRF cookie. This flag prevents the cookie from being sent in cross-site requests. See [`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) for details about `SameSite`. > **Changed in Django 3.1** > > Setting `CSRF_COOKIE_SAMESITE = 'None'` was allowed. ### `CSRF_COOKIE_SECURE` デフォルト値: `False` Whether to use a secure cookie for the CSRF cookie. If this is set to `True`, the cookie will be marked as "secure", which means browsers may ensure that the cookie is only sent with an HTTPS connection. ### `CSRF_USE_SESSIONS` デフォルト値: `False` Whether to store the CSRF token in the user's session instead of in a cookie. It requires the use of [`django.contrib.sessions`](/ja/3.2/topics/http/sessions/#module-django.contrib.sessions). Storing the CSRF token in a cookie (Django's default) is safe, but storing it in the session is common practice in other web frameworks and therefore sometimes demanded by security auditors. Since the [default error views](/ja/3.2/ref/views/#error-views) require the CSRF token, [`SessionMiddleware`](/ja/3.2/ref/middleware/#django.contrib.sessions.middleware.SessionMiddleware) must appear in [`MIDDLEWARE`](#std-setting-MIDDLEWARE) before any middleware that may raise an exception to trigger an error view (such as [`PermissionDenied`](/ja/3.2/ref/exceptions/#django.core.exceptions.PermissionDenied)) if you're using `CSRF_USE_SESSIONS`. See [Middleware の順序](/ja/3.2/ref/middleware/#middleware-ordering). ### `CSRF_FAILURE_VIEW` デフォルト値: `'django.views.csrf.csrf_failure'` A dotted path to the view function to be used when an incoming request is rejected by the [CSRF protection](/ja/3.2/ref/csrf/). The function should have this signature: ``` def csrf_failure(request, reason=""): ... ``` where `reason` is a short message (intended for developers or logging, not for end users) indicating the reason the request was rejected. It should return an [`HttpResponseForbidden`](/ja/3.2/ref/request-response/#django.http.HttpResponseForbidden). `django.views.csrf.csrf_failure()` accepts an additional `template_name` parameter that defaults to `'403_csrf.html'`. If a template with that name exists, it will be used to render the page. ### `CSRF_HEADER_NAME` デフォルト値: `'HTTP_X_CSRFTOKEN'` The name of the request header used for CSRF authentication. As with other HTTP headers in `request.META`, the header name received from the server is normalized by converting all characters to uppercase, replacing any hyphens with underscores, and adding an `'HTTP_'` prefix to the name. For example, if your client sends a `'X-XSRF-TOKEN'` header, the setting should be `'HTTP_X_XSRF_TOKEN'`. ### `CSRF_TRUSTED_ORIGINS` デフォルト値: `[]` (空のリスト) A list of hosts which are trusted origins for unsafe requests (e.g. `POST`). For a [`secure`](/ja/3.2/ref/request-response/#django.http.HttpRequest.is_secure) unsafe request, Django's CSRF protection requires that the request have a `Referer` header that matches the origin present in the `Host` header. This prevents, for example, a `POST` request from `subdomain.example.com` from succeeding against `api.example.com`. If you need cross-origin unsafe requests over HTTPS, continuing the example, add `"subdomain.example.com"` to this list. The setting also supports subdomains, so you could add `".example.com"`, for example, to allow access from all subdomains of `example.com`. ### `DATABASES` デフォルト値: `{}` (空の辞書) A dictionary containing the settings for all databases to be used with Django. It is a nested dictionary whose contents map a database alias to a dictionary containing the options for an individual database. The [`DATABASES`](#std-setting-DATABASES) setting must configure a `default` database; any number of additional databases may also be specified. The simplest possible settings file is for a single-database setup using SQLite. This can be configured using the following: ``` DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'mydatabase', } } ``` When connecting to other database backends, such as MariaDB, MySQL, Oracle, or PostgreSQL, additional connection parameters will be required. See the [`ENGINE`](#std-setting-DATABASE-ENGINE) setting below on how to specify other database types. This example is for PostgreSQL: ``` DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'mydatabase', 'USER': 'mydatabaseuser', 'PASSWORD': 'mypassword', 'HOST': '127.0.0.1', 'PORT': '5432', } } ``` The following inner options that may be required for more complex configurations are available: #### `ATOMIC_REQUESTS` デフォルト値: `False` Set this to `True` to wrap each view in a transaction on this database. See [HTTP リクエストにトランザクションを結びつける](/ja/3.2/topics/db/transactions/#tying-transactions-to-http-requests). #### `AUTOCOMMIT` デフォルト値: `True` Set this to `False` if you want to [disable Django's transaction management](/ja/3.2/topics/db/transactions/#deactivate-transaction-management) and implement your own. #### `ENGINE` デフォルト値: `''` (空文字列) The database backend to use. The built-in database backends are: - `'django.db.backends.postgresql'` - `'django.db.backends.mysql'` - `'django.db.backends.sqlite3'` - `'django.db.backends.oracle'` You can use a database backend that doesn't ship with Django by setting `ENGINE` to a fully-qualified path (i.e. `mypackage.backends.whatever`). #### `HOST` デフォルト値: `''` (空文字列) Which host to use when connecting to the database. An empty string means localhost. Not used with SQLite. If this value starts with a forward slash (`'/'`) and you're using MySQL, MySQL will connect via a Unix socket to the specified socket. For example: ``` "HOST": '/var/run/mysql' ``` If you're using MySQL and this value *doesn't* start with a forward slash, then this value is assumed to be the host. If you're using PostgreSQL, by default (empty [`HOST`](#std-setting-HOST)), the connection to the database is done through UNIX domain sockets ('local' lines in `pg_hba.conf`). If your UNIX domain socket is not in the standard location, use the same value of `unix_socket_directory` from `postgresql.conf`. If you want to connect through TCP sockets, set [`HOST`](#std-setting-HOST) to 'localhost' or '127.0.0.1' ('host' lines in `pg_hba.conf`). On Windows, you should always define [`HOST`](#std-setting-HOST), as UNIX domain sockets are not available. #### `NAME` デフォルト値: `''` (空文字列) The name of the database to use. For SQLite, it's the full path to the database file. When specifying the path, always use forward slashes, even on Windows (e.g. `C:/homes/user/mysite/sqlite3.db`). #### `CONN_MAX_AGE` デフォルト値: `0` The lifetime of a database connection, as an integer of seconds. Use `0` to close database connections at the end of each request — Django's historical behavior — and `None` for unlimited persistent connections. #### `OPTIONS` デフォルト値: `{}` (空の辞書) Extra parameters to use when connecting to the database. Available parameters vary depending on your database backend. Some information on available parameters can be found in the [Database Backends](/ja/3.2/ref/databases/) documentation. For more information, consult your backend module's own documentation. #### `PASSWORD` デフォルト値: `''` (空文字列) The password to use when connecting to the database. Not used with SQLite. #### `PORT` デフォルト値: `''` (空文字列) The port to use when connecting to the database. An empty string means the default port. Not used with SQLite. #### `TIME_ZONE` デフォルト値: `None` A string representing the time zone for this database connection or `None`. This inner option of the [`DATABASES`](#std-setting-DATABASES) setting accepts the same values as the general [`TIME_ZONE`](#std-setting-TIME_ZONE) setting. When [`USE_TZ`](#std-setting-USE_TZ) is `True` and this option is set, reading datetimes from the database returns aware datetimes in this time zone instead of UTC. When [`USE_TZ`](#std-setting-USE_TZ) is `False`, it is an error to set this option. - If the database backend doesn't support time zones (e.g. SQLite, MySQL, Oracle), Django reads and writes datetimes in local time according to this option if it is set and in UTC if it isn't. Changing the connection time zone changes how datetimes are read from and written to the database. - If Django manages the database and you don't have a strong reason to do otherwise, you should leave this option unset. It's best to store datetimes in UTC because it avoids ambiguous or nonexistent datetimes during daylight saving time changes. Also, receiving datetimes in UTC keeps datetime arithmetic simple — there's no need for the `normalize()` method provided by pytz. - If you're connecting to a third-party database that stores datetimes in a local time rather than UTC, then you must set this option to the appropriate time zone. Likewise, if Django manages the database but third-party systems connect to the same database and expect to find datetimes in local time, then you must set this option. - If the database backend supports time zones (e.g. PostgreSQL), the `TIME_ZONE` option is very rarely needed. It can be changed at any time; the database takes care of converting datetimes to the desired time zone. Setting the time zone of the database connection may be useful for running raw SQL queries involving date/time functions provided by the database, such as `date_trunc`, because their results depend on the time zone. However, this has a downside: receiving all datetimes in local time makes datetime arithmetic more tricky — you must call the `normalize()` method provided by pytz after each operation. Consider converting to local time explicitly with `AT TIME ZONE` in raw SQL queries instead of setting the `TIME_ZONE` option. > **Changed in Django 3.1** > > Using this option when the database backend supports time zones was allowed. #### `DISABLE_SERVER_SIDE_CURSORS` デフォルト値: `False` Set this to `True` if you want to disable the use of server-side cursors with [`QuerySet.iterator()`](/ja/3.2/ref/models/querysets/#django.db.models.query.QuerySet.iterator). [Transaction pooling and server-side cursors](/ja/3.2/ref/databases/#transaction-pooling-server-side-cursors) describes the use case. This is a PostgreSQL-specific setting. #### `USER` デフォルト値: `''` (空文字列) The username to use when connecting to the database. Not used with SQLite. #### `TEST` デフォルト値: `{}` (空の辞書) A dictionary of settings for test databases; for more details about the creation and use of test databases, see [test データベース](/ja/3.2/topics/testing/overview/#the-test-database). Here's an example with a test database configuration: ``` DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'USER': 'mydatabaseuser', 'NAME': 'mydatabase', 'TEST': { 'NAME': 'mytestdatabase', }, }, } ``` The following keys in the `TEST` dictionary are available: ##### `CHARSET` デフォルト値: `None` The character set encoding used to create the test database. The value of this string is passed directly through to the database, so its format is backend-specific. Supported by the [PostgreSQL](https://www.postgresql.org/docs/current/multibyte.html) (`postgresql`) and [MySQL](https://dev.mysql.com/doc/refman/en/charset-charsets.html) (`mysql`) backends. ##### `COLLATION` デフォルト値: `None` The collation order to use when creating the test database. This value is passed directly to the backend, so its format is backend-specific. Only supported for the `mysql` backend (see the [MySQL manual](https://dev.mysql.com/doc/refman/en/charset-charsets.html) for details). ##### `DEPENDENCIES` Default: `['default']`, for all databases other than `default`, which has no dependencies. The creation-order dependencies of the database. See the documentation on [controlling the creation order of test databases](/ja/3.2/topics/testing/advanced/#topics-testing-creation-dependencies) for details. ##### `MIGRATE` > **New in Django 3.1** デフォルト値: `True` When set to `False`, migrations won't run when creating the test database. This is similar to setting `None` as a value in [`MIGRATION_MODULES`](#std-setting-MIGRATION_MODULES), but for all apps. ##### `MIRROR` デフォルト値: `None` The alias of the database that this database should mirror during testing. This setting exists to allow for testing of primary/replica (referred to as master/slave by some databases) configurations of multiple databases. See the documentation on [testing primary/replica configurations](/ja/3.2/topics/testing/advanced/#topics-testing-primaryreplica) for details. ##### `NAME` デフォルト値: `None` The name of database to use when running the test suite. If the default value (`None`) is used with the SQLite database engine, the tests will use a memory resident database. For all other database engines the test database will use the name `'test_' + DATABASE_NAME`. See [test データベース](/ja/3.2/topics/testing/overview/#the-test-database). ##### `SERIALIZE` Boolean value to control whether or not the default test runner serializes the database into an in-memory JSON string before running tests (used to restore the database state between tests if you don't have transactions). You can set this to `False` to speed up creation time if you don't have any test classes with [serialized\_rollback=True](/ja/3.2/topics/testing/overview/#test-case-serialized-rollback). ##### `TEMPLATE` This is a PostgreSQL-specific setting. The name of a [template](https://www.postgresql.org/docs/current/sql-createdatabase.html) (e.g. `'template0'`) from which to create the test database. ##### `CREATE_DB` デフォルト値: `True` This is an Oracle-specific setting. If it is set to `False`, the test tablespaces won't be automatically created at the beginning of the tests or dropped at the end. ##### `CREATE_USER` デフォルト値: `True` This is an Oracle-specific setting. If it is set to `False`, the test user won't be automatically created at the beginning of the tests and dropped at the end. ##### `USER` デフォルト値: `None` This is an Oracle-specific setting. The username to use when connecting to the Oracle database that will be used when running tests. If not provided, Django will use `'test_' + USER`. ##### `PASSWORD` デフォルト値: `None` This is an Oracle-specific setting. The password to use when connecting to the Oracle database that will be used when running tests. If not provided, Django will generate a random password. ##### `ORACLE_MANAGED_FILES` デフォルト値: `False` This is an Oracle-specific setting. If set to `True`, Oracle Managed Files (OMF) tablespaces will be used. [`DATAFILE`](#std-setting-DATAFILE) and [`DATAFILE_TMP`](#std-setting-DATAFILE_TMP) will be ignored. ##### `TBLSPACE` デフォルト値: `None` This is an Oracle-specific setting. The name of the tablespace that will be used when running tests. If not provided, Django will use `'test_' + USER`. ##### `TBLSPACE_TMP` デフォルト値: `None` This is an Oracle-specific setting. The name of the temporary tablespace that will be used when running tests. If not provided, Django will use `'test_' + USER + '_temp'`. ##### `DATAFILE` デフォルト値: `None` This is an Oracle-specific setting. The name of the datafile to use for the TBLSPACE. If not provided, Django will use `TBLSPACE + '.dbf'`. ##### `DATAFILE_TMP` デフォルト値: `None` This is an Oracle-specific setting. The name of the datafile to use for the TBLSPACE\_TMP. If not provided, Django will use `TBLSPACE_TMP + '.dbf'`. ##### `DATAFILE_MAXSIZE` デフォルト値: `'500M'` This is an Oracle-specific setting. The maximum size that the DATAFILE is allowed to grow to. ##### `DATAFILE_TMP_MAXSIZE` デフォルト値: `'500M'` This is an Oracle-specific setting. The maximum size that the DATAFILE\_TMP is allowed to grow to. ##### `DATAFILE_SIZE` Default: `'50M'` This is an Oracle-specific setting. The initial size of the DATAFILE. ##### `DATAFILE_TMP_SIZE` Default: `'50M'` This is an Oracle-specific setting. The initial size of the DATAFILE\_TMP. ##### `DATAFILE_EXTSIZE` Default: `'25M'` This is an Oracle-specific setting. The amount by which the DATAFILE is extended when more space is required. ##### `DATAFILE_TMP_EXTSIZE` Default: `'25M'` This is an Oracle-specific setting. The amount by which the DATAFILE\_TMP is extended when more space is required. ### `DATA_UPLOAD_MAX_MEMORY_SIZE` デフォルト値: `2621440` (例: 2.5 MB)。 The maximum size in bytes that a request body may be before a [`SuspiciousOperation`](/ja/3.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`RequestDataTooBig`) is raised. The check is done when accessing `request.body` or `request.POST` and is calculated against the total request size excluding any file upload data. You can set this to `None` to disable the check. Applications that are expected to receive unusually large form posts should tune this setting. The amount of request data is correlated to the amount of memory needed to process the request and populate the GET and POST dictionaries. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don't typically perform deep request inspection, it's not possible to perform a similar check at that level. See also [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE). ### `DATA_UPLOAD_MAX_NUMBER_FIELDS` デフォルト値: `1000` The maximum number of parameters that may be received via GET or POST before a [`SuspiciousOperation`](/ja/3.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`TooManyFields`) is raised. You can set this to `None` to disable the check. Applications that are expected to receive an unusually large number of form fields should tune this setting. The number of request parameters is correlated to the amount of time needed to process the request and populate the GET and POST dictionaries. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don't typically perform deep request inspection, it's not possible to perform a similar check at that level. ### `DATA_UPLOAD_MAX_NUMBER_FILES` > **New in Django 3.2.18** Default: `100` The maximum number of files that may be received via POST in a `multipart/form-data` encoded request before a [`SuspiciousOperation`](/ja/3.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`TooManyFiles`) is raised. You can set this to `None` to disable the check. Applications that are expected to receive an unusually large number of file fields should tune this setting. The number of accepted files is correlated to the amount of time and memory needed to process the request. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don't typically perform deep request inspection, it's not possible to perform a similar check at that level. ### `DATABASE_ROUTERS` デフォルト値: `[]` (空のリスト) The list of routers that will be used to determine which database to use when performing a database query. See the documentation on [automatic database routing in multi database configurations](/ja/3.2/topics/db/multi-db/#topics-db-multi-db-routing). ### `DATE_FORMAT` デフォルト値: `'N j, Y'` (例: `Feb. 4, 2003`) The default formatting to use for displaying date fields in any part of the system. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) and [`SHORT_DATE_FORMAT`](#std-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' ] ``` A list of formats that will be accepted when inputting data on a date field. Formats will be tried in order, using the first valid one. Note that these format strings use Python's [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date) template filter. When [`USE_L10N`](#std-setting-USE_L10N) is `True`, the locale-dictated format has higher precedence and will be applied instead. See also [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) and [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS). ### `DATETIME_FORMAT` デフォルト値: `'N j, Y, P'` (例: `Feb. 4, 2003, 4 p.m.`) The default formatting to use for displaying datetime fields in any part of the system. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) and [`SHORT_DATETIME_FORMAT`](#std-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' ] ``` A list of formats that will be accepted when inputting data on a datetime field. Formats will be tried in order, using the first valid one. Note that these format strings use Python's [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date) template filter. Date-only formats are not included as datetime fields will automatically try [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) in last resort. When [`USE_L10N`](#std-setting-USE_L10N) is `True`, the locale-dictated format has higher precedence and will be applied instead. See also [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) and [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS). > **Changed in Django 3.1** > > In older versions, the default is a list containing also date-only formats. ### `DEBUG` デフォルト値: `False` A boolean that turns on/off debug mode. Never deploy a site into production with [`DEBUG`](#std-setting-DEBUG) turned on. One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when [`DEBUG`](#std-setting-DEBUG) is `True`, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from `settings.py`). As a security measure, Django will *not* include settings that might be sensitive, such as [`SECRET_KEY`](#std-setting-SECRET_KEY). Specifically, it will exclude any setting whose name includes any of the following: - `'API'` - `'KEY'` - `'PASS'` - `'SECRET'` - `'SIGNATURE'` - `'TOKEN'` Note that these are *partial* matches. `'PASS'` will also match PASSWORD, just as `'TOKEN'` will also match TOKENIZED and so on. Still, note that there are always going to be sections of your debug output that are inappropriate for public consumption. File paths, configuration options and the like all give attackers extra information about your server. It is also important to remember that when running with [`DEBUG`](#std-setting-DEBUG) turned on, Django will remember every SQL query it executes. This is useful when you're debugging, but it'll rapidly consume memory on a production server. Finally, if [`DEBUG`](#std-setting-DEBUG) is `False`, you also need to properly set the [`ALLOWED_HOSTS`](#std-setting-ALLOWED_HOSTS) setting. Failing to do so will result in all requests being returned as "Bad Request (400)". > **Note** > > The default `settings.py` file created by [`django-admin > startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) sets `DEBUG = True` for convenience. ### `DEBUG_PROPAGATE_EXCEPTIONS` デフォルト値: `False` If set to `True`, Django's exception handling of view functions ([`handler500`](/ja/3.2/ref/urls/#django.conf.urls.handler500), or the debug view if [`DEBUG`](#std-setting-DEBUG) is `True`) and logging of 500 responses ([django.request](/ja/3.2/topics/logging/#django-request-logger)) is skipped and exceptions propagate upwards. This can be useful for some test setups. It shouldn't be used on a live site unless you want your web server (instead of Django) to generate "Internal Server Error" responses. In that case, make sure your server doesn't show the stack trace or other sensitive information in the response. ### `DECIMAL_SEPARATOR` デフォルト値: `'.'` (ドット) Default decimal separator used when formatting decimal numbers. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. See also [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) and [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR). ### `DEFAULT_AUTO_FIELD` > **New in Django 3.2** Default: `'`[`django.db.models.AutoField`](/ja/3.2/ref/models/fields/#django.db.models.AutoField)`'` Default primary key field type to use for models that don't have a field with [`primary_key=True`](/ja/3.2/ref/models/fields/#django.db.models.Field.primary_key). > **Migrating auto-created through tables** > > The value of `DEFAULT_AUTO_FIELD` will be respected when creating new > auto-created through tables for many-to-many relationships. > > Unfortunately, the primary keys of existing auto-created through tables > cannot currently be updated by the migrations framework. > > This means that if you switch the value of `DEFAULT_AUTO_FIELD` and then > generate migrations, the primary keys of the related models will be > updated, as will the foreign keys from the through table, but the primary > key of the auto-created through table will not be migrated. > > In order to address this, you should add a > [`RunSQL`](/ja/3.2/ref/migration-operations/#django.db.migrations.operations.RunSQL) operation to your > migrations to perform the required `ALTER TABLE` step. You can check the > existing table name through `sqlmigrate`, `dbshell`, or with the > field’s `remote_field.through._meta.db_table` property. > > Explicitly defined through models are already handled by the migrations > system. > > Allowing automatic migrations for the primary key of existing auto-created > through tables [may be implemented at a later date](https://code.djangoproject.com/ticket/32674). ### `DEFAULT_CHARSET` デフォルト値: `'utf-8'` Default charset to use for all `HttpResponse` objects, if a MIME type isn't manually specified. Used when constructing the `Content-Type` header. ### `DEFAULT_EXCEPTION_REPORTER` > **New in Django 3.1** Default: `'`[`django.views.debug.ExceptionReporter`](/ja/3.2/howto/error-reporting/#django.views.debug.ExceptionReporter)`'` Default exception reporter class to be used if none has been assigned to the [`HttpRequest`](/ja/3.2/ref/request-response/#django.http.HttpRequest) instance yet. See [Custom error reports](/ja/3.2/howto/error-reporting/#custom-error-reports). ### `DEFAULT_EXCEPTION_REPORTER_FILTER` デフォルト値: `'`[`django.views.debug.SafeExceptionReporterFilter`](/ja/3.2/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter)`'` Default exception reporter filter class to be used if none has been assigned to the [`HttpRequest`](/ja/3.2/ref/request-response/#django.http.HttpRequest) instance yet. See [Filtering error reports](/ja/3.2/howto/error-reporting/#filtering-error-reports). ### `DEFAULT_FILE_STORAGE` デフォルト値: `'`[`django.core.files.storage.FileSystemStorage`](/ja/3.2/ref/files/storage/#django.core.files.storage.FileSystemStorage)`'` Default file storage class to be used for any file-related operations that don't specify a particular storage system. See [ファイルの管理](/ja/3.2/topics/files/). ### `DEFAULT_FROM_EMAIL` デフォルト値: `'webmaster@localhost'` Default email address to use for various automated correspondence from the site manager(s). This doesn't include error messages sent to [`ADMINS`](#std-setting-ADMINS) and [`MANAGERS`](#std-setting-MANAGERS); for that, see [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL). ### `DEFAULT_HASHING_ALGORITHM` > **New in Django 3.1** Default: `'sha256'` Default hashing algorithm to use for encoding cookies, password reset tokens in the admin site, user sessions, and signatures created by [`django.core.signing.Signer`](/ja/3.2/topics/signing/#django.core.signing.Signer) and [`django.core.signing.dumps()`](/ja/3.2/topics/signing/#django.core.signing.dumps). Algorithm must be `'sha1'` or `'sha256'`. See [release notes](/ja/3.2/releases/3.1/#default-hashing-algorithm-usage) for usage details. > **Deprecated since Django 3.1** > > バージョン 3.1 で非推奨: This transitional setting is deprecated. Support for it and tokens, > cookies, sessions, and signatures that use SHA-1 hashing algorithm will be > removed in Django 4.0. ### `DEFAULT_INDEX_TABLESPACE` デフォルト値: `''` (空文字列) Default tablespace to use for indexes on fields that don't specify one, if the backend supports it (see [Tablespaces](/ja/3.2/topics/db/tablespaces/)). ### `DEFAULT_TABLESPACE` デフォルト値: `''` (空文字列) Default tablespace to use for models that don't specify one, if the backend supports it (see [Tablespaces](/ja/3.2/topics/db/tablespaces/)). ### `DISALLOWED_USER_AGENTS` デフォルト値: `[]` (空のリスト) List of compiled regular expression objects representing User-Agent strings that are not allowed to visit any page, systemwide. Use this for bots/crawlers. This is only used if `CommonMiddleware` is installed (see [ミドルウェア (Middleware)](/ja/3.2/topics/http/middleware/)). ### `EMAIL_BACKEND` デフォルト値: `'`[`django.core.mail.backends.smtp.EmailBackend`](/ja/3.2/topics/email/#django.core.mail.backends.smtp.EmailBackend)`'` E メール送信に使われるバックエンドです。利用可能なバックエンドのリストは [メールを送信する](/ja/3.2/topics/email/) を参照してください。 ### `EMAIL_FILE_PATH` デフォルト値: 定義されていません The directory used by the [file email backend](/ja/3.2/topics/email/#topic-email-file-backend) to store output files. > **Changed in Django 3.1** > > Support for [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path) was added. ### `EMAIL_HOST` デフォルト値: `'localhost'` E メール送信に使われるホストです。 [`EMAIL_PORT`](#std-setting-EMAIL_PORT) も参照してください。 ### `EMAIL_HOST_PASSWORD` デフォルト値: `''` (空文字列) [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるパスワードです。この設定は、STMP サーバへの認証の際に [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) と組み合わせて用いられます。どちらかの設定が空の場合、Django は認証を試みません。 [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) も参照してください。 ### `EMAIL_HOST_USER` デフォルト値: `''` (空文字列) [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるユーザ名です。空の場合、Django は認証を試みません。 [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD) も参照してください。 ### `EMAIL_PORT` デフォルト値: `25` [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるポート番号です。 ### `EMAIL_SUBJECT_PREFIX` デフォルト値: `'[Django] '` `django.core.mail.mail_admins` や `django.core.mail.mail_managers` で送信される E メールメッセージ用の表題行のプレフィックスです。最後の文字はスペースにするのが良いでしょう。 ### `EMAIL_USE_LOCALTIME` デフォルト値: `False` Whether to send the SMTP `Date` header of email messages in the local time zone (`True`) or in UTC (`False`). ### `EMAIL_USE_TLS` デフォルト値: `False` SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。明示的な TLS 接続に使われ、通常はポート 587 で行われます。接続がハングしてしまう場合は、暗黙的な TLS を示す [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) を確認してみてください。 ### `EMAIL_USE_SSL` デフォルト値: `False` SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。ほとんどの E メールのドキュメントでは、この TLS 接続のタイプは SSL として参照されます。通常はポート 465 が使われます。接続がハングしてしまう場合は、暗黙的な TLS を示す [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) を確認してみてください。 [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS)/[`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) は相互に排他的であることに注意してください。したがって、どちらか一方だけを `True` にセットしてください。 ### `EMAIL_SSL_CERTFILE` デフォルト値: `None` [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) ないし [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) が `True` の場合、オプションで、SSL 接続用に使う PEM フォーマットの証明書チェーンファイルを指定することができます。 ### `EMAIL_SSL_KEYFILE` デフォルト値: `None` [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) ないし [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) が `True` の場合、オプションで、SSL 接続用に使う PEM フォーマットのプライベートキーファイルを指定することができます。 設定 [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) と [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) は証明書チェックには使われません。これらは元の SSL 接続に渡されます。証明書チェーンファイルとプライベートキーファイルがどのように処理されるかについての詳細は、パイソンの `python:ssl.wrap_socket()` 関数のドキュメントを参照してください。 ### `EMAIL_TIMEOUT` デフォルト値: `None` 接続試行のような操作をブロックするためのタイムアウトを秒で指定します。 ### `FILE_UPLOAD_HANDLERS` デフォルト値: ``` [ 'django.core.files.uploadhandler.MemoryFileUploadHandler', 'django.core.files.uploadhandler.TemporaryFileUploadHandler', ] ``` A list of handlers to use for uploading. Changing this setting allows complete customization -- even replacement -- of Django's upload process. See [ファイルの管理](/ja/3.2/topics/files/) for details. ### `FILE_UPLOAD_MAX_MEMORY_SIZE` デフォルト値: `2621440` (例: 2.5 MB)。 The maximum size (in bytes) that an upload will be before it gets streamed to the file system. See [ファイルの管理](/ja/3.2/topics/files/) for details. See also [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE). ### `FILE_UPLOAD_DIRECTORY_PERMISSIONS` デフォルト値: `None` The numeric mode to apply to directories created in the process of uploading files. This setting also determines the default permissions for collected static directories when using the [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command. See [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) for details on overriding it. This value mirrors the functionality and caveats of the [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS) setting. ### `FILE_UPLOAD_PERMISSIONS` Default: `0o644` The numeric mode (i.e. `0o644`) to set newly uploaded files to. For more information about what these modes mean, see the documentation for [`os.chmod()`](https://docs.python.org/3/library/os.html#os.chmod). If `None`, you'll get operating-system dependent behavior. On most platforms, temporary files will have a mode of `0o600`, and files saved from memory will be saved using the system's standard umask. For security reasons, these permissions aren't applied to the temporary files that are stored in [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR). This setting also determines the default permissions for collected static files when using the [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command. See [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) for details on overriding it. > **Warning** > > **Always prefix the mode with** `0o` **.** > > If you're not familiar with file modes, please note that the `0o` prefix > is very important: it indicates an octal number, which is the way that > modes must be specified. If you try to use `644`, you'll get totally > incorrect behavior. ### `FILE_UPLOAD_TEMP_DIR` デフォルト値: `None` The directory to store data to (typically files larger than [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE)) temporarily while uploading files. If `None`, Django will use the standard temporary directory for the operating system. For example, this will default to `/tmp` on \*nix-style operating systems. See [ファイルの管理](/ja/3.2/topics/files/) for details. ### `FIRST_DAY_OF_WEEK` デフォルト値: `0` (日曜日) A number representing the first day of the week. This is especially useful when displaying a calendar. This value is only used when not using format internationalization, or when a format cannot be found for the current locale. The value must be an integer from 0 to 6, where 0 means Sunday, 1 means Monday and so on. ### `FIXTURE_DIRS` デフォルト値: `[]` (空のリスト) List of directories searched for fixture files, in addition to the `fixtures` directory of each application, in search order. Note that these paths should use Unix-style forward slashes, even on Windows. See [フィクスチャでデータを投入する](/ja/3.2/howto/initial-data/#initial-data-via-fixtures) and [フィクスチャーのロード](/ja/3.2/topics/testing/tools/#topics-testing-fixtures). ### `FORCE_SCRIPT_NAME` デフォルト値: `None` If not `None`, this will be used as the value of the `SCRIPT_NAME` environment variable in any HTTP request. This setting can be used to override the server-provided value of `SCRIPT_NAME`, which may be a rewritten version of the preferred value or not supplied at all. It is also used by [`django.setup()`](/ja/3.2/ref/applications/#django.setup) to set the URL resolver script prefix outside of the request/response cycle (e.g. in management commands and standalone scripts) to generate correct URLs when `SCRIPT_NAME` is not `/`. ### `FORM_RENDERER` Default: `'`[`django.forms.renderers.DjangoTemplates`](/ja/3.2/ref/forms/renderers/#django.forms.renderers.DjangoTemplates)`'` The class that renders form widgets. It must implement [the low-level render API](/ja/3.2/ref/forms/renderers/#low-level-widget-render-api). Included form renderers are: - `'`[`django.forms.renderers.DjangoTemplates`](/ja/3.2/ref/forms/renderers/#django.forms.renderers.DjangoTemplates)`'` - `'`[`django.forms.renderers.Jinja2`](/ja/3.2/ref/forms/renderers/#django.forms.renderers.Jinja2)`'` ### `FORMAT_MODULE_PATH` デフォルト値: `None` A full Python path to a Python package that contains custom format definitions for project locales. If not `None`, Django will check for a `formats.py` file, under the directory named as the current locale, and will use the formats defined in this file. For example, if [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH) is set to `mysite.formats`, and current language is `en` (English), Django will expect a directory tree like: ``` mysite/ formats/ __init__.py en/ __init__.py formats.py ``` You can also set this setting to a list of Python paths, for example: ``` FORMAT_MODULE_PATH = [ 'mysite.formats', 'some_app.formats', ] ``` When Django searches for a certain format, it will go through all given Python paths until it finds a module that actually defines the given format. This means that formats defined in packages farther up in the list will take precedence over the same formats in packages farther down. Available formats are: - [`DATE_FORMAT`](#std-setting-DATE_FORMAT) - [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) - [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), - [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) - [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) - [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK) - [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT) - [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) - [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) - [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) - [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) - [`TIME_FORMAT`](#std-setting-TIME_FORMAT) - [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) - [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) ### `IGNORABLE_404_URLS` デフォルト値: `[]` (空のリスト) List of compiled regular expression objects describing URLs that should be ignored when reporting HTTP 404 errors via email (see [エラーのレポート](/ja/3.2/howto/error-reporting/)). Regular expressions are matched against [`request's full paths`](/ja/3.2/ref/request-response/#django.http.HttpRequest.get_full_path) (including query string, if any). Use this if your site does not provide a commonly requested file such as `favicon.ico` or `robots.txt`. This is only used if [`BrokenLinkEmailsMiddleware`](/ja/3.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) is enabled (see [ミドルウェア (Middleware)](/ja/3.2/topics/http/middleware/)). ### `INSTALLED_APPS` デフォルト値: `[]` (空のリスト) A list of strings designating all applications that are enabled in this Django installation. Each string should be a dotted Python path to: - an application configuration class (preferred), or - a package containing an application. [Learn more about application configurations](/ja/3.2/ref/applications/). > **Use the application registry for introspection** > > Your code should never access [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) directly. Use > [`django.apps.apps`](/ja/3.2/ref/applications/#django.apps.apps) instead. > **Application names and labels must be unique in > INSTALLED_APPS** > > Application [`names`](/ja/3.2/ref/applications/#django.apps.AppConfig.name) — the dotted Python > path to the application package — must be unique. There is no way to > include the same application twice, short of duplicating its code under > another name. > > Application [`labels`](/ja/3.2/ref/applications/#django.apps.AppConfig.label) — by default the > final part of the name — must be unique too. For example, you can't > include both `django.contrib.auth` and `myproject.auth`. However, you > can relabel an application with a custom configuration that defines a > different [`label`](/ja/3.2/ref/applications/#django.apps.AppConfig.label). > > These rules apply regardless of whether [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) > references application configuration classes or application packages. When several applications provide different versions of the same resource (template, static file, management command, translation), the application listed first in [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) has precedence. ### `INTERNAL_IPS` デフォルト値: `[]` (空のリスト) A list of IP addresses, as strings, that: - Allow the [`debug()`](/ja/3.2/ref/templates/api/#django.template.context_processors.debug) context processor to add some variables to the template context. - Can use the [admindocs bookmarklets](/ja/3.2/ref/contrib/admin/admindocs/#admindocs-bookmarklets) even if not logged in as a staff user. - Are marked as "internal" (as opposed to "EXTERNAL") in [`AdminEmailHandler`](/ja/3.2/topics/logging/#django.utils.log.AdminEmailHandler) emails. ### `LANGUAGE_CODE` デフォルト値: `'en-us'` このインストールに対する言語コードを表す文字列です。標準の [言語 ID フォーマット](/ja/3.2/topics/i18n/#term-language-code) 内にある文字列を指定します。例えば、U.S. の英語は `"en-us"` です。[list of language identifiers](http://www.i18nguy.com/unicode/language-identifiers.html) と [国際化とローカル化](/ja/3.2/topics/i18n/) も参照してください。 この設定が効果を持つためには、[`USE_I18N`](#std-setting-USE_I18N) をアクティブにする必要があります。 これは 2 つの目的に使われます: - ロケールミドルウェアが使用されていない場合、全ユーザにどの翻訳を提供するかを決めます。 - ロケールミドルウェアがアクティブの場合、ユーザの好む言語が不明な場合やウェブサイトでサポートされていない場合に備えて、フォールバックの言語として利用されます。また、与えられた文字列に対して、ユーザの好む言語に対応する翻訳が存在しない場合にも、この設定が利用されます。 詳しくは [How Django discovers language preference](/ja/3.2/topics/i18n/translation/#how-django-discovers-language-preference) を参照してください。 ### `LANGUAGE_COOKIE_AGE` デフォルト値: `None` (ブラウザを閉じると期限切れとなります) 言語クッキーの age で、秒で表します。 ### `LANGUAGE_COOKIE_DOMAIN` デフォルト値: `None` The domain to use for the language cookie. Set this to a string such as `"example.com"` for cross-domain cookies, or use `None` for a standard domain cookie. Be cautious when updating this setting on a production site. If you update this setting to enable cross-domain cookies on a site that previously used standard domain cookies, existing user cookies that have the old domain will not be updated. This will result in site users being unable to switch the language as long as these cookies persist. The only safe and reliable option to perform the switch is to change the language cookie name permanently (via the [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) setting) and to add a middleware that copies the value from the old cookie to a new one and then deletes the old one. ### `LANGUAGE_COOKIE_HTTPONLY` デフォルト値: `False` Whether to use `HttpOnly` flag on the language cookie. If this is set to `True`, client-side JavaScript will not be able to access the language cookie. See [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) for details on `HttpOnly`. ### `LANGUAGE_COOKIE_NAME` デフォルト値: `'django_language'` The name of the cookie to use for the language cookie. This can be whatever you want (as long as it's different from the other cookie names in your application). See [国際化とローカル化](/ja/3.2/topics/i18n/). ### `LANGUAGE_COOKIE_PATH` デフォルト値: `'/'` The path set on the language cookie. This should either match the URL path of your Django installation or be a parent of that path. This is useful if you have multiple Django instances running under the same hostname. They can use different cookie paths and each instance will only see its own language cookie. Be cautious when updating this setting on a production site. If you update this setting to use a deeper path than it previously used, existing user cookies that have the old path will not be updated. This will result in site users being unable to switch the language as long as these cookies persist. The only safe and reliable option to perform the switch is to change the language cookie name permanently (via the [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) setting), and to add a middleware that copies the value from the old cookie to a new one and then deletes the one. ### `LANGUAGE_COOKIE_SAMESITE` デフォルト値: `None` The value of the [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) flag on the language cookie. This flag prevents the cookie from being sent in cross-site requests. See [`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) for details about `SameSite`. > **Changed in Django 3.1** > > Setting `LANGUAGE_COOKIE_SAMESITE = 'None'` was allowed. ### `LANGUAGE_COOKIE_SECURE` デフォルト値: `False` Whether to use a secure cookie for the language cookie. If this is set to `True`, the cookie will be marked as "secure", which means browsers may ensure that the cookie is only sent under an HTTPS connection. ### `LANGUAGES` Default: A list of all available languages. This list is continually growing and including a copy here would inevitably become rapidly out of date. You can see the current list of translated languages by looking in [django/conf/global\_settings.py](https://github.com/django/django/blob/stable/3.2.x/django/conf/global_settings.py). このリストは、([言語コード](/ja/3.2/topics/i18n/#term-language-code), `言語名`) 形式の 2 タプルのリストです -- 例えば `('ja', 'Japanese')` です。これはどの言語が言語選択で利用可能かを指定します。[国際化とローカル化](/ja/3.2/topics/i18n/) を参照してください。 一般的には、デフォルト値で十分です。Django が提供する言語の部分集合に選択肢を限定したいときにのみ、この設定を自分でセットしてください。 If you define a custom [`LANGUAGES`](#std-setting-LANGUAGES) setting, you can mark the language names as translation strings using the [`gettext_lazy()`](/ja/3.2/ref/utils/#django.utils.translation.gettext_lazy) function. 以下はサンプルの設定ファイルです: ``` from django.utils.translation import gettext_lazy as _ LANGUAGES = [ ('de', _('German')), ('en', _('English')), ] ``` ### `LANGUAGES_BIDI` Default: A list of all language codes that are written right-to-left. You can see the current list of these languages by looking in [django/conf/global\_settings.py](https://github.com/django/django/blob/stable/3.2.x/django/conf/global_settings.py). The list contains [language codes](/ja/3.2/topics/i18n/#term-language-code) for languages that are written right-to-left. Generally, the default value should suffice. Only set this setting if you want to restrict language selection to a subset of the Django-provided languages. If you define a custom [`LANGUAGES`](#std-setting-LANGUAGES) setting, the list of bidirectional languages may contain language codes which are not enabled on a given site. ### `LOCALE_PATHS` デフォルト値: `[]` (空のリスト) Django が翻訳ファイルを探すディレクトリのリストです。[How Django discovers translations](/ja/3.2/topics/i18n/translation/#how-django-discovers-translations) を参照してください。 実装例: ``` LOCALE_PATHS = [ '/home/www/project/common_files/locale', '/var/local/translations/locale', ] ``` Django は、実際の翻訳ファイルを含む `/LC_MESSAGES` ディレクトリに対して、これらのパス内をそれぞれ見ていきます。 ### `LOGGING` デフォルト値: ロギング設定のディレクトリ。 A data structure containing configuration information. The contents of this data structure will be passed as the argument to the configuration method described in [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG). Among other things, the default logging configuration passes HTTP 500 server errors to an email log handler when [`DEBUG`](#std-setting-DEBUG) is `False`. See also [ロギングを設定する](/ja/3.2/topics/logging/#configuring-logging). You can see the default logging configuration by looking in [django/utils/log.py](https://github.com/django/django/blob/stable/3.2.x/django/utils/log.py). ### `LOGGING_CONFIG` デフォルト値: `'logging.config.dictConfig'` A path to a callable that will be used to configure logging in the Django project. Points at an instance of Python's [dictConfig](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) configuration method by default. If you set [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) to `None`, the logging configuration process will be skipped. ### `MANAGERS` デフォルト値: `[]` (空のリスト) A list in the same format as [`ADMINS`](#std-setting-ADMINS) that specifies who should get broken link notifications when [`BrokenLinkEmailsMiddleware`](/ja/3.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) is enabled. ### `MEDIA_ROOT` デフォルト値: `''` (空文字列) Absolute filesystem path to the directory that will hold [user-uploaded files](/ja/3.2/topics/files/). Example: `"/var/www/example.com/media/"` See also [`MEDIA_URL`](#std-setting-MEDIA_URL). > **Warning** > > [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) and [`STATIC_ROOT`](#std-setting-STATIC_ROOT) must have different > values. Before [`STATIC_ROOT`](#std-setting-STATIC_ROOT) was introduced, it was common to > rely or fallback on [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) to also serve static files; > however, since this can have serious security implications, there is a > validation check to prevent it. ### `MEDIA_URL` デフォルト値: `''` (空文字列) URL that handles the media served from [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT), used for [managing stored files](/ja/3.2/topics/files/). It must end in a slash if set to a non-empty value. You will need to [configure these files to be served](/ja/3.2/howto/static-files/#serving-uploaded-files-in-development) in both development and production environments. If you want to use `{{ MEDIA_URL }}` in your templates, add `'django.template.context_processors.media'` in the `'context_processors'` option of [`TEMPLATES`](#std-setting-TEMPLATES). Example: `"http://media.example.com/"` > **Warning** > > 信頼できないユーザーからコンテンツアップロードを許可する場合、セキュリティリスクが存在します！緩和策の詳細は、[ユーザーがアップロードしたコンテンツ](/ja/3.2/topics/security/#user-uploaded-content-security) のセキュリティガイドをご覧ください。 > **Warning** > > [`MEDIA_URL`](#std-setting-MEDIA_URL) and [`STATIC_URL`](#std-setting-STATIC_URL) must have different > values. See [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) for more details. > **Note** > > If [`MEDIA_URL`](#std-setting-MEDIA_URL) is a relative path, then it will be prefixed by the > server-provided value of `SCRIPT_NAME` (or `/` if not set). This makes > it easier to serve a Django application in a subpath without adding an > extra configuration to the settings. ### `MIDDLEWARE` デフォルト値: `None` A list of middleware to use. See [ミドルウェア (Middleware)](/ja/3.2/topics/http/middleware/). ### `MIGRATION_MODULES` デフォルト値: `{}` (空の辞書) A dictionary specifying the package where migration modules can be found on a per-app basis. The default value of this setting is an empty dictionary, but the default package name for migration modules is `migrations`. 実装例: ``` {'blog': 'blog.db_migrations'} ``` In this case, migrations pertaining to the `blog` app will be contained in the `blog.db_migrations` package. If you provide the `app_label` argument, [`makemigrations`](/ja/3.2/ref/django-admin/#django-admin-makemigrations) will automatically create the package if it doesn't already exist. When you supply `None` as a value for an app, Django will consider the app as an app without migrations regardless of an existing `migrations` submodule. This can be used, for example, in a test settings file to skip migrations while testing (tables will still be created for the apps' models). To disable migrations for all apps during tests, you can set the [`MIGRATE`](#std-setting-TEST_MIGRATE) to `False` instead. If `MIGRATION_MODULES` is used in your general project settings, remember to use the [`migrate --run-syncdb`](/ja/3.2/ref/django-admin/#cmdoption-migrate-run-syncdb) option if you want to create tables for the app. ### `MONTH_DAY_FORMAT` デフォルト値: `'F j'` admin change-list のページの日付をフォーマットする時のデフォルト値です。システムの他の場所で月と日だけが表示される場合に使用される可能性があります。 たとえば、Django の admin change-list のページを日付でフィルタする時、与えられた日付のヘッダには月と日が表示されます。 [`USE_L10N`](#std-setting-USE_L10N) を `True` に設定すると、ロケールに基づいた対応するフォーマットが高い優先度で適用されるので気をつけてください。 [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。また、[`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT), [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) も参照してください。 ### `NUMBER_GROUPING` デフォルト値: `0` 数の整数部分をまとめるときの桁数です。 よくある使われ方は、1000倍の区切り文字を表示するときです。`0` に設定すると、数に対してグルーピングを行いません。`0` より大きい値を指定すると、 [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) が区切り位置を求めるのに使います。 Some locales use non-uniform digit grouping, e.g. `10,00,00,000` in `en_IN`. For this case, you can provide a sequence with the number of digit group sizes to be applied. The first number defines the size of the group preceding the decimal delimiter, and each number that follows defines the size of preceding groups. If the sequence is terminated with `-1`, no further grouping is performed. If the sequence terminates with a `0`, the last group size is used for the remainder of the number. Example tuple for `en_IN`: ``` NUMBER_GROUPING = (3, 2, 0) ``` Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR), [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) も参照してください。 ### `PREPEND_WWW` デフォルト値: `False` "www." サブドメインが URL に含まれていない時、自動的に頭に追加するかどうかを指定します。この設定が有効になるのは、 [`CommonMiddleware`](/ja/3.2/ref/middleware/#django.middleware.common.CommonMiddleware) がインストールされている時のみです (参照: [ミドルウェア (Middleware)](/ja/3.2/topics/http/middleware/))。[`APPEND_SLASH`](#std-setting-APPEND_SLASH) も参照してください。 ### `ROOT_URLCONF` デフォルト値: 定義されていません A string representing the full Python import path to your root URLconf, for example `"mydjangoapps.urls"`. Can be overridden on a per-request basis by setting the attribute `urlconf` on the incoming `HttpRequest` object. See [Django のリクエスト処理](/ja/3.2/topics/http/urls/#how-django-processes-a-request) for details. ### `SECRET_KEY` デフォルト値: `''` (空文字列) Django のインストールごとに設定される個別の秘密鍵です。[cryptographic signing](/ja/3.2/topics/signing/) に使われる鍵であり、ユニークかつ予測できない値でなければなりません。 [`django-admin startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) コマンドを実行すると、新しいプロジェクトを作成するたびに、ランダムに生成された `SECRET_KEY` を自動的に設定してくれます。 Uses of the key shouldn't assume that it's text or bytes. Every use should go through [`force_str()`](/ja/3.2/ref/utils/#django.utils.encoding.force_str) or [`force_bytes()`](/ja/3.2/ref/utils/#django.utils.encoding.force_bytes) to convert it to the desired type. [`SECRET_KEY`](#std-setting-SECRET_KEY) が設定されていない場合、Django は起動しません。 > **Warning** > > **この値は、絶対に秘密にしてください。** > > Django を既知の [`SECRET_KEY`](#std-setting-SECRET_KEY) で実行してしまうと、Django の多数のセキュリティプロテクションが破られ、結果的に、コンピュータの重要な権限が取得されてリモートコード実行の脆弱性に晒されてしまいます。 秘密鍵は次のような場合に使われます。 - All [sessions](/ja/3.2/topics/http/sessions/) if you are using any other session backend than `django.contrib.sessions.backends.cache`, or are using the default [`get_session_auth_hash()`](/ja/3.2/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash). - All [messages](/ja/3.2/ref/contrib/messages/) if you are using [`CookieStorage`](/ja/3.2/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) or [`FallbackStorage`](/ja/3.2/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage). - All [`PasswordResetView`](/ja/3.2/topics/auth/default/#django.contrib.auth.views.PasswordResetView) tokens. - Any usage of [cryptographic signing](/ja/3.2/topics/signing/), unless a different key is provided. If you rotate your secret key, all of the above will be invalidated. Secret keys are not used for passwords of users and key rotation will not affect them. > **Note** > > The default `settings.py` file created by [`django-admin > startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) creates a unique `SECRET_KEY` for > convenience. ### `SECURE_BROWSER_XSS_FILTER` デフォルト値: `False` If `True`, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) sets the [X-XSS-Protection: 1; mode=block](/ja/3.2/ref/middleware/#x-xss-protection) header on all responses that do not already have it. Modern browsers don't honor `X-XSS-Protection` HTTP header anymore. Although the setting offers little practical benefit, you may still want to set the header if you support older browsers. ### `SECURE_CONTENT_TYPE_NOSNIFF` デフォルト値: `True` If `True`, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) sets the [X-Content-Type-Options: nosniff](/ja/3.2/ref/middleware/#x-content-type-options) header on all responses that do not already have it. ### `SECURE_HSTS_INCLUDE_SUBDOMAINS` デフォルト値: `False` If `True`, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) adds the `includeSubDomains` directive to the [HTTP Strict Transport Security](/ja/3.2/ref/middleware/#http-strict-transport-security) header. It has no effect unless [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) is set to a non-zero value. > **Warning** > > Setting this incorrectly can irreversibly (for the value of > [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS)) break your site. Read the > [HTTP Strict Transport Security](/ja/3.2/ref/middleware/#http-strict-transport-security) documentation first. ### `SECURE_HSTS_PRELOAD` デフォルト値: `False` If `True`, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) adds the `preload` directive to the [HTTP Strict Transport Security](/ja/3.2/ref/middleware/#http-strict-transport-security) header. It has no effect unless [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) is set to a non-zero value. ### `SECURE_HSTS_SECONDS` デフォルト値: `0` If set to a non-zero integer value, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) sets the [HTTP Strict Transport Security](/ja/3.2/ref/middleware/#http-strict-transport-security) header on all responses that do not already have it. > **Warning** > > Setting this incorrectly can irreversibly (for some time) break your site. > Read the [HTTP Strict Transport Security](/ja/3.2/ref/middleware/#http-strict-transport-security) documentation first. ### `SECURE_PROXY_SSL_HEADER` デフォルト値: `None` A tuple representing a HTTP header/value combination that signifies a request is secure. This controls the behavior of the request object's `is_secure()` method. By default, `is_secure()` determines if a request is secure by confirming that a requested URL uses `https://`. This method is important for Django's CSRF protection, and it may be used by your own code or third-party apps. If your Django app is behind a proxy, though, the proxy may be "swallowing" whether the original request uses HTTPS or not. If there is a non-HTTPS connection between the proxy and Django then `is_secure()` would always return `False` -- even for requests that were made via HTTPS by the end user. In contrast, if there is an HTTPS connection between the proxy and Django then `is_secure()` would always return `True` -- even for requests that were made originally via HTTP. In this situation, configure your proxy to set a custom HTTP header that tells Django whether the request came in via HTTPS, and set `SECURE_PROXY_SSL_HEADER` so that Django knows what header to look for. Set a tuple with two elements -- the name of the header to look for and the required value. For example: ``` SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') ``` This tells Django to trust the `X-Forwarded-Proto` header that comes from our proxy, and any time its value is `'https'`, then the request is guaranteed to be secure (i.e., it originally came in via HTTPS). You should *only* set this setting if you control your proxy or have some other guarantee that it sets/strips this header appropriately. Note that the header needs to be in the format as used by `request.META` -- all caps and likely starting with `HTTP_`. (Remember, Django automatically adds `'HTTP_'` to the start of x-header names before making the header available in `request.META`.) > **Warning** > > **Modifying this setting can compromise your site's security. Ensure you > fully understand your setup before changing it.** > > Make sure ALL of the following are true before setting this (assuming the > values from the example above): > > - Your Django app is behind a proxy. > - Your proxy strips the `X-Forwarded-Proto` header from all incoming > requests. In other words, if end users include that header in their > requests, the proxy will discard it. > - Your proxy sets the `X-Forwarded-Proto` header and sends it to Django, > but only for requests that originally come in via HTTPS. > > If any of those are not true, you should keep this setting set to `None` > and find another way of determining HTTPS, perhaps via custom middleware. ### `SECURE_REDIRECT_EXEMPT` デフォルト値: `[]` (空のリスト) If a URL path matches a regular expression in this list, the request will not be redirected to HTTPS. The [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) strips leading slashes from URL paths, so patterns shouldn't include them, e.g. `SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]`. If [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) is `False`, this setting has no effect. ### `SECURE_REFERRER_POLICY` Default: `'same-origin'` If configured, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) sets the [Referrer Policy](/ja/3.2/ref/middleware/#referrer-policy) header on all responses that do not already have it to the value provided. > **Changed in Django 3.1** > > In older versions, the default value is `None`. ### `SECURE_SSL_HOST` デフォルト値: `None` If a string (e.g. `secure.example.com`), all SSL redirects will be directed to this host rather than the originally-requested host (e.g. `www.example.com`). If [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) is `False`, this setting has no effect. ### `SECURE_SSL_REDIRECT` デフォルト値: `False` If `True`, the [`SecurityMiddleware`](/ja/3.2/ref/middleware/#django.middleware.security.SecurityMiddleware) [redirects](/ja/3.2/ref/middleware/#ssl-redirect) all non-HTTPS requests to HTTPS (except for those URLs matching a regular expression listed in [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT)). > **Note** > > If turning this to `True` causes infinite redirects, it probably means > your site is running behind a proxy and can't tell which requests are secure > and which are not. Your proxy likely sets a header to indicate secure > requests; you can correct the problem by finding out what that header is and > configuring the [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER) setting accordingly. ### `SERIALIZATION_MODULES` デフォルト値: 定義されていません A dictionary of modules containing serializer definitions (provided as strings), keyed by a string identifier for that serialization type. For example, to define a YAML serializer, use: ``` SERIALIZATION_MODULES = {'yaml': 'path.to.yaml_serializer'} ``` ### `SERVER_EMAIL` デフォルト値: `'root@localhost'` The email address that error messages come from, such as those sent to [`ADMINS`](#std-setting-ADMINS) and [`MANAGERS`](#std-setting-MANAGERS). > **Why are my emails sent from a different address?** > > This address is used only for error messages. It is *not* the address that > regular email messages sent with [`send_mail()`](/ja/3.2/topics/email/#django.core.mail.send_mail) > come from; for that, see [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL). ### `SHORT_DATE_FORMAT` デフォルト値: `'m/d/Y'` (例: `12/31/2003`) An available formatting that can be used for displaying date fields on templates. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the corresponding locale-dictated format has higher precedence and will be applied. See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATE_FORMAT`](#std-setting-DATE_FORMAT) and [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT). ### `SHORT_DATETIME_FORMAT` デフォルト値: `'m/d/Y P'` (例: `12/31/2003 4 p.m.`) An available formatting that can be used for displaying datetime fields on templates. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the corresponding locale-dictated format has higher precedence and will be applied. See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATE_FORMAT`](#std-setting-DATE_FORMAT) and [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT). ### `SIGNING_BACKEND` デフォルト値: `'django.core.signing.TimestampSigner'` The backend used for signing cookies and other data. See also the [暗号署名](/ja/3.2/topics/signing/) documentation. ### `SILENCED_SYSTEM_CHECKS` デフォルト値: `[]` (空のリスト) A list of identifiers of messages generated by the system check framework (i.e. `["models.W001"]`) that you wish to permanently acknowledge and ignore. Silenced checks will not be output to the console. See also the [システムチェックフレームワーク](/ja/3.2/ref/checks/) documentation. ### `TEMPLATES` デフォルト値: `[]` (空のリスト) A list containing the settings for all template engines to be used with Django. Each item of the list is a dictionary containing the options for an individual engine. Here's a setup that tells the Django template engine to load templates from the `templates` subdirectory inside each installed application: ``` TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'APP_DIRS': True, }, ] ``` The following options are available for all backends. #### `BACKEND` デフォルト値: 定義されていません The template backend to use. The built-in template backends are: - `'django.template.backends.django.DjangoTemplates'` - `'django.template.backends.jinja2.Jinja2'` You can use a template backend that doesn't ship with Django by setting `BACKEND` to a fully-qualified path (i.e. `'mypackage.whatever.Backend'`). #### `NAME` デフォルト値: 下記をご覧ください The alias for this particular template engine. It's an identifier that allows selecting an engine for rendering. Aliases must be unique across all configured template engines. It defaults to the name of the module defining the engine class, i.e. the next to last piece of [`BACKEND`](#std-setting-TEMPLATES-BACKEND), when it isn't provided. For example if the backend is `'mypackage.whatever.Backend'` then its default name is `'whatever'`. #### `DIRS` デフォルト値: `[]` (空のリスト) Directories where the engine should look for template source files, in search order. #### `APP_DIRS` デフォルト値: `False` Whether the engine should look for template source files inside installed applications. > **Note** > > The default `settings.py` file created by [`django-admin > startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) sets `'APP_DIRS': True`. #### `OPTIONS` デフォルト値: `{}` (空のディクショナリ) Extra parameters to pass to the template backend. Available parameters vary depending on the template backend. See [`DjangoTemplates`](/ja/3.2/topics/templates/#django.template.backends.django.DjangoTemplates) and [`Jinja2`](/ja/3.2/topics/templates/#django.template.backends.jinja2.Jinja2) for the options of the built-in backends. ### `TEST_RUNNER` デフォルト値: `'django.test.runner.DiscoverRunner'` The name of the class to use for starting the test suite. See [Using different testing frameworks](/ja/3.2/topics/testing/advanced/#other-testing-frameworks). ### `TEST_NON_SERIALIZED_APPS` デフォルト値: `[]` (空のリスト) In order to restore the database state between tests for `TransactionTestCase`s and database backends without transactions, Django will [serialize the contents of all apps](/ja/3.2/topics/testing/overview/#test-case-serialized-rollback) when it starts the test run so it can then reload from that copy before running tests that need it. This slows down the startup time of the test runner; if you have apps that you know don't need this feature, you can add their full names in here (e.g. `'django.contrib.contenttypes'`) to exclude them from this serialization process. ### `THOUSAND_SEPARATOR` デフォルト値: `','` (カンマ) Default thousand separator used when formatting numbers. This setting is used only when [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) is `True` and [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) is greater than `0`. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. See also [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) and [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR). ### `TIME_FORMAT` デフォルト値: `'P'` (例: `4 p.m.`) The default formatting to use for displaying time fields in any part of the system. Note that if [`USE_L10N`](#std-setting-USE_L10N) is set to `True`, then the locale-dictated format has higher precedence and will be applied instead. See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATE_FORMAT`](#std-setting-DATE_FORMAT) and [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT). ### `TIME_INPUT_FORMATS` デフォルト値: ``` [ '%H:%M:%S', # '14:30:59' '%H:%M:%S.%f', # '14:30:59.000200' '%H:%M', # '14:30' ] ``` A list of formats that will be accepted when inputting data on a time field. Formats will be tried in order, using the first valid one. Note that these format strings use Python's [datetime module syntax](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), not the format strings from the [`date`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date) template filter. When [`USE_L10N`](#std-setting-USE_L10N) is `True`, the locale-dictated format has higher precedence and will be applied instead. See also [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) and [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS). ### `TIME_ZONE` デフォルト値: `'America/Chicago'` A string representing the time zone for this installation. See the [list of time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). > **Note** > > Django は最初 [`TIME_ZONE`](#std-setting-TIME_ZONE) を `'America/Chicago'` にしてリリースされていたので、後方互換性のために (プロジェクト内で `settings.py` が定義されていないときに使われる) グローバル設定は `'America/Chicago'` のままになっています。新しいプロジェクトのテンプレートではデフォルトは `'UTC'` です。 これは必ずしもサーバのタイムゾーンではないことに注意してください。例えば、1 つのサーバ内に Django 製のサイトがあり、それぞれが異なるタイムゾーン設定を持つこともできます。 [`USE_TZ`](#std-setting-USE_TZ) が `False` のとき、これは Django が日時を保持するタイムゾーンとなります。[`USE_TZ`](#std-setting-USE_TZ) が `True` のとき、これは Django がテンプレート内で日時を表示するため、およびフォーム内で入力された日時を解釈するために使う、デフォルトのタイムゾーンです。 On Unix environments (where [`time.tzset()`](https://docs.python.org/3/library/time.html#time.tzset) is implemented), Django sets the `os.environ['TZ']` variable to the time zone you specify in the [`TIME_ZONE`](#std-setting-TIME_ZONE) setting. Thus, all your views and models will automatically operate in this time zone. However, Django won't set the `TZ` environment variable if you're using the manual configuration option as described in [manually configuring settings](/ja/3.2/topics/settings/#settings-without-django-settings-module). If Django doesn't set the `TZ` environment variable, it's up to you to ensure your processes are running in the correct environment. > **Note** > > Django は、Windows 環境で代替タイムゾーンを正しく扱うことができません。Django を Windows で実行している場合、[`TIME_ZONE`](#std-setting-TIME_ZONE) はシステムのタイムゾーンに合わせてセットする必要があります。 ### `USE_I18N` デフォルト値: `True` A boolean that specifies whether Django's translation system should be enabled. This provides a way to turn it off, for performance. If this is set to `False`, Django will make some optimizations so as not to load the translation machinery. See also [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE), [`USE_L10N`](#std-setting-USE_L10N) and [`USE_TZ`](#std-setting-USE_TZ). > **Note** > > The default `settings.py` file created by [`django-admin > startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) includes `USE_I18N = True` for convenience. ### `USE_L10N` デフォルト値: `False` A boolean that specifies if localized formatting of data will be enabled by default or not. If this is set to `True`, e.g. Django will display numbers and dates using the format of the current locale. See also [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE), [`USE_I18N`](#std-setting-USE_I18N) and [`USE_TZ`](#std-setting-USE_TZ). > **Note** > > The default `settings.py` file created by [`django-admin > startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) includes `USE_L10N = True` for convenience. ### `USE_THOUSAND_SEPARATOR` デフォルト値: `False` A boolean that specifies whether to display numbers using a thousand separator. When set to `True` and [`USE_L10N`](#std-setting-USE_L10N) is also `True`, Django will format numbers using the [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) and [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) settings. These settings may also be dictated by the locale, which takes precedence. See also [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) and [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR). ### `USE_TZ` デフォルト値: `False` A boolean that specifies if datetimes will be timezone-aware by default or not. If this is set to `True`, Django will use timezone-aware datetimes internally. When `USE_TZ` is False, Django will use naive datetimes in local time, except when parsing ISO 8601 formatted strings, where timezone information will always be retained if present. See also [`TIME_ZONE`](#std-setting-TIME_ZONE), [`USE_I18N`](#std-setting-USE_I18N) and [`USE_L10N`](#std-setting-USE_L10N). > **Note** > > The default `settings.py` file created by > [`django-admin startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) includes > `USE_TZ = True` for convenience. ### `USE_X_FORWARDED_HOST` デフォルト値: `False` A boolean that specifies whether to use the `X-Forwarded-Host` header in preference to the `Host` header. This should only be enabled if a proxy which sets this header is in use. This setting takes priority over [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT). Per [**RFC 7239 Section 5.3**](https://datatracker.ietf.org/doc/html/rfc7239.html#section-5.3), the `X-Forwarded-Host` header can include the port number, in which case you shouldn't use [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT). ### `USE_X_FORWARDED_PORT` デフォルト値: `False` A boolean that specifies whether to use the `X-Forwarded-Port` header in preference to the `SERVER_PORT` `META` variable. This should only be enabled if a proxy which sets this header is in use. [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) takes priority over this setting. ### `WSGI_APPLICATION` デフォルト値: `None` The full Python path of the WSGI application object that Django's built-in servers (e.g. [`runserver`](/ja/3.2/ref/django-admin/#django-admin-runserver)) will use. The [`django-admin startproject`](/ja/3.2/ref/django-admin/#django-admin-startproject) management command will create a standard `wsgi.py` file with an `application` callable in it, and point this setting to that `application`. If not set, the return value of `django.core.wsgi.get_wsgi_application()` will be used. In this case, the behavior of [`runserver`](/ja/3.2/ref/django-admin/#django-admin-runserver) will be identical to previous Django versions. ### `YEAR_MONTH_FORMAT` デフォルト値: `'F Y'` The default formatting to use for date fields on Django admin change-list pages -- and, possibly, by other parts of the system -- in cases when only the year and month are displayed. For example, when a Django admin change-list page is being filtered by a date drilldown, the header for a given month displays the month and the year. Different locales have different formats. For example, U.S. English would say "January 2006," whereas another locale might say "2006/January." [`USE_L10N`](#std-setting-USE_L10N) を `True` に設定すると、ロケールに基づいた対応するフォーマットが高い優先度で適用されるので気をつけてください。 See [`allowed date format strings`](/ja/3.2/ref/templates/builtins/#std-templatefilter-date). See also [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT) and [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT). ### `X_FRAME_OPTIONS` Default: `'DENY'` The default value for the X-Frame-Options header used by [`XFrameOptionsMiddleware`](/ja/3.2/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware). See the [clickjacking protection](/ja/3.2/ref/clickjacking/) documentation. ## Auth Settings for [`django.contrib.auth`](/ja/3.2/topics/auth/#module-django.contrib.auth). ### `AUTHENTICATION_BACKENDS` デフォルト値: `['django.contrib.auth.backends.ModelBackend']` A list of authentication backend classes (as strings) to use when attempting to authenticate a user. See the [authentication backends documentation](/ja/3.2/topics/auth/customizing/#authentication-backends) for details. ### `AUTH_USER_MODEL` デフォルト値: `'auth.User'` User を表すために使うモデルです。[カスタムの User モデルを置き換える](/ja/3.2/topics/auth/customizing/#auth-custom-user) を参照してください。 > **Warning** > > You cannot change the AUTH\_USER\_MODEL setting during the lifetime of > a project (i.e. once you have made and migrated models that depend on it) > without serious effort. It is intended to be set at the project start, > and the model it refers to must be available in the first migration of > the app that it lives in. > See [カスタムの User モデルを置き換える](/ja/3.2/topics/auth/customizing/#auth-custom-user) for more details. ### `LOGIN_REDIRECT_URL` デフォルト値: `'/accounts/profile/'` The URL or [named URL pattern](/ja/3.2/topics/http/urls/#naming-url-patterns) where requests are redirected after login when the [`LoginView`](/ja/3.2/topics/auth/default/#django.contrib.auth.views.LoginView) doesn't get a `next` GET parameter. ### `LOGIN_URL` デフォルト値: `'/accounts/login/'` The URL or [named URL pattern](/ja/3.2/topics/http/urls/#naming-url-patterns) where requests are redirected for login when using the [`login_required()`](/ja/3.2/topics/auth/default/#django.contrib.auth.decorators.login_required) decorator, [`LoginRequiredMixin`](/ja/3.2/topics/auth/default/#django.contrib.auth.mixins.LoginRequiredMixin), or [`AccessMixin`](/ja/3.2/topics/auth/default/#django.contrib.auth.mixins.AccessMixin). ### `LOGOUT_REDIRECT_URL` デフォルト値: `None` The URL or [named URL pattern](/ja/3.2/topics/http/urls/#naming-url-patterns) where requests are redirected after logout if [`LogoutView`](/ja/3.2/topics/auth/default/#django.contrib.auth.views.LogoutView) doesn't have a `next_page` attribute. If `None`, no redirect will be performed and the logout view will be rendered. ### `PASSWORD_RESET_TIMEOUT` > **New in Django 3.1** Default: `259200` (3 days, in seconds) The number of seconds a password reset link is valid for. Used by the [`PasswordResetConfirmView`](/ja/3.2/topics/auth/default/#django.contrib.auth.views.PasswordResetConfirmView). > **Note** > > Reducing the value of this timeout doesn't make any difference to the > ability of an attacker to brute-force a password reset token. Tokens are > designed to be safe from brute-forcing without any timeout. > > This timeout exists to protect against some unlikely attack scenarios, such > as someone gaining access to email archives that may contain old, unused > password reset tokens. ### `PASSWORD_RESET_TIMEOUT_DAYS` デフォルト値: `3` The number of days a password reset link is valid for. Used by the [`PasswordResetConfirmView`](/ja/3.2/topics/auth/default/#django.contrib.auth.views.PasswordResetConfirmView). > **Deprecated since Django 3.1** > > バージョン 3.1 で非推奨: This setting is deprecated. Use [`PASSWORD_RESET_TIMEOUT`](#std-setting-PASSWORD_RESET_TIMEOUT) instead. ### `PASSWORD_HASHERS` See [Djangoのパスワード保存方法](/ja/3.2/topics/auth/passwords/#auth-password-storage). デフォルト値: ``` [ 'django.contrib.auth.hashers.PBKDF2PasswordHasher', 'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher', 'django.contrib.auth.hashers.Argon2PasswordHasher', 'django.contrib.auth.hashers.BCryptSHA256PasswordHasher', ] ``` ### `AUTH_PASSWORD_VALIDATORS` デフォルト値: `[]` (空のリスト) The list of validators that are used to check the strength of user's passwords. See [パスワードの妥当性検証](/ja/3.2/topics/auth/passwords/#password-validation) for more details. By default, no validation is performed and all passwords are accepted. ## メッセージ Settings for [`django.contrib.messages`](/ja/3.2/ref/contrib/messages/#module-django.contrib.messages). ### `MESSAGE_LEVEL` デフォルト値: `messages.INFO` Sets the minimum message level that will be recorded by the messages framework. See [message levels](/ja/3.2/ref/contrib/messages/#message-level) for more details. > **Important** > > If you override `MESSAGE_LEVEL` in your settings file and rely on any of > the built-in constants, you must import the constants module directly to > avoid the potential for circular imports, e.g.: > > ``` > from django.contrib.messages import constants as message_constants > MESSAGE_LEVEL = message_constants.DEBUG > ``` > > If desired, you may specify the numeric values for the constants directly > according to the values in the above [constants table](/ja/3.2/ref/contrib/messages/#message-level-constants). ### `MESSAGE_STORAGE` デフォルト値: `'django.contrib.messages.storage.fallback.FallbackStorage'` Controls where Django stores message data. Valid values are: - `'django.contrib.messages.storage.fallback.FallbackStorage'` - `'django.contrib.messages.storage.session.SessionStorage'` - `'django.contrib.messages.storage.cookie.CookieStorage'` See [message storage backends](/ja/3.2/ref/contrib/messages/#message-storage-backends) for more details. The backends that use cookies -- [`CookieStorage`](/ja/3.2/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) and [`FallbackStorage`](/ja/3.2/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage) -- use the value of [`SESSION_COOKIE_DOMAIN`](#std-setting-SESSION_COOKIE_DOMAIN), [`SESSION_COOKIE_SECURE`](#std-setting-SESSION_COOKIE_SECURE) and [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) when setting their cookies. ### `MESSAGE_TAGS` デフォルト値: ``` { messages.DEBUG: 'debug', messages.INFO: 'info', messages.SUCCESS: 'success', messages.WARNING: 'warning', messages.ERROR: 'error', } ``` This sets the mapping of message level to message tag, which is typically rendered as a CSS class in HTML. If you specify a value, it will extend the default. This means you only have to specify those values which you need to override. See [メッセージを表示する](/ja/3.2/ref/contrib/messages/#message-displaying) above for more details. > **Important** > > If you override `MESSAGE_TAGS` in your settings file and rely on any of > the built-in constants, you must import the `constants` module directly to > avoid the potential for circular imports, e.g.: > > ``` > from django.contrib.messages import constants as message_constants > MESSAGE_TAGS = {message_constants.INFO: ''} > ``` > > If desired, you may specify the numeric values for the constants directly > according to the values in the above [constants table](/ja/3.2/ref/contrib/messages/#message-level-constants). ## セッション Settings for [`django.contrib.sessions`](/ja/3.2/topics/http/sessions/#module-django.contrib.sessions). ### `SESSION_CACHE_ALIAS` デフォルト値: `'default'` If you're using [cache-based session storage](/ja/3.2/topics/http/sessions/#cached-sessions-backend), this selects the cache to use. ### `SESSION_COOKIE_AGE` デフォルト値: `1209600` (2 週間の秒表記) The age of session cookies, in seconds. ### `SESSION_COOKIE_DOMAIN` デフォルト値: `None` The domain to use for session cookies. Set this to a string such as `"example.com"` for cross-domain cookies, or use `None` for a standard domain cookie. To use cross-domain cookies with [`CSRF_USE_SESSIONS`](#std-setting-CSRF_USE_SESSIONS), you must include a leading dot (e.g. `".example.com"`) to accommodate the CSRF middleware's referer checking. Be cautious when updating this setting on a production site. If you update this setting to enable cross-domain cookies on a site that previously used standard domain cookies, existing user cookies will be set to the old domain. This may result in them being unable to log in as long as these cookies persist. This setting also affects cookies set by [`django.contrib.messages`](/ja/3.2/ref/contrib/messages/#module-django.contrib.messages). ### `SESSION_COOKIE_HTTPONLY` デフォルト値: `True` Whether to use `HttpOnly` flag on the session cookie. If this is set to `True`, client-side JavaScript will not be able to access the session cookie. [HttpOnly](https://owasp.org/www-community/HttpOnly) is a flag included in a Set-Cookie HTTP response header. It's part of the [**RFC 6265 Section 4.1.2.6**](https://datatracker.ietf.org/doc/html/rfc6265.html#section-4.1.2.6) standard for cookies and can be a useful way to mitigate the risk of a client-side script accessing the protected cookie data. This makes it less trivial for an attacker to escalate a cross-site scripting vulnerability into full hijacking of a user's session. There aren't many good reasons for turning this off. Your code shouldn't read session cookies from JavaScript. ### `SESSION_COOKIE_NAME` デフォルト値: `'sessionid'` The name of the cookie to use for sessions. This can be whatever you want (as long as it's different from the other cookie names in your application). ### `SESSION_COOKIE_PATH` デフォルト値: `'/'` The path set on the session cookie. This should either match the URL path of your Django installation or be parent of that path. This is useful if you have multiple Django instances running under the same hostname. They can use different cookie paths, and each instance will only see its own session cookie. ### `SESSION_COOKIE_SAMESITE` Default: `'Lax'` The value of the [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) flag on the session cookie. This flag prevents the cookie from being sent in cross-site requests thus preventing CSRF attacks and making some methods of stealing session cookie impossible. Possible values for the setting are: - `'Strict'`: prevents the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user won't be able to access the project. A bank website, however, most likely doesn't want to allow any transactional pages to be linked from external sites so the `'Strict'` flag would be appropriate. - `'Lax'` (default): provides a balance between security and usability for websites that want to maintain user's logged-in session after the user arrives from an external link. In the GitHub scenario, the session cookie would be allowed when following a regular link from an external website and be blocked in CSRF-prone request methods (e.g. `POST`). - `'None'` (string): the session cookie will be sent with all same-site and cross-site requests. - `False`: disables the flag. > **Note** > > Modern browsers provide a more secure default policy for the `SameSite` > flag and will assume `Lax` for cookies without an explicit value set. > **Changed in Django 3.1** > > Setting `SESSION_COOKIE_SAMESITE = 'None'` was allowed. ### `SESSION_COOKIE_SECURE` デフォルト値: `False` Whether to use a secure cookie for the session cookie. If this is set to `True`, the cookie will be marked as "secure", which means browsers may ensure that the cookie is only sent under an HTTPS connection. Leaving this setting off isn't a good idea because an attacker could capture an unencrypted session cookie with a packet sniffer and use the cookie to hijack the user's session. ### `SESSION_ENGINE` デフォルト値: `'django.contrib.sessions.backends.db'` Controls where Django stores session data. Included engines are: - `'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'` See [セッションエンジンを設定する](/ja/3.2/topics/http/sessions/#configuring-sessions) for more details. ### `SESSION_EXPIRE_AT_BROWSER_CLOSE` デフォルト値: `False` Whether to expire the session when the user closes their browser. See [ブラウザ起動中のみ有効なセッション vs. 永続的なセッション](/ja/3.2/topics/http/sessions/#browser-length-vs-persistent-sessions). ### `SESSION_FILE_PATH` デフォルト値: `None` If you're using file-based session storage, this sets the directory in which Django will store session data. When the default value (`None`) is used, Django will use the standard temporary directory for the system. ### `SESSION_SAVE_EVERY_REQUEST` デフォルト値: `False` Whether to save the session data on every request. If this is `False` (default), then the session data will only be saved if it has been modified -- that is, if any of its dictionary values have been assigned or deleted. Empty sessions won't be created, even if this setting is active. ### `SESSION_SERIALIZER` デフォルト値: `'django.contrib.sessions.serializers.JSONSerializer'` Full import path of a serializer class to use for serializing session data. Included serializers are: - `'django.contrib.sessions.serializers.PickleSerializer'` - `'django.contrib.sessions.serializers.JSONSerializer'` See [セッションのシリアライズ](/ja/3.2/topics/http/sessions/#session-serialization) for details, including a warning regarding possible remote code execution when using [`PickleSerializer`](/ja/3.2/topics/http/sessions/#django.contrib.sessions.serializers.PickleSerializer). ## サイト Settings for [`django.contrib.sites`](/ja/3.2/ref/contrib/sites/#module-django.contrib.sites). ### `SITE_ID` デフォルト値: 定義されていません The ID, as an integer, of the current site in the `django_site` database table. This is used so that application data can hook into specific sites and a single database can manage content for multiple sites. ## 静的ファイル Settings for [`django.contrib.staticfiles`](/ja/3.2/ref/contrib/staticfiles/#module-django.contrib.staticfiles). ### `STATIC_ROOT` デフォルト値: `None` The absolute path to the directory where [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) will collect static files for deployment. Example: `"/var/www/example.com/static/"` If the [staticfiles](/ja/3.2/ref/contrib/staticfiles/) contrib app is enabled (as in the default project template), the [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command will collect static files into this directory. See the how-to on [managing static files](/ja/3.2/howto/static-files/) for more details about usage. > **Warning** > > This should be an initially empty destination directory for collecting > your static files from their permanent locations into one directory for > ease of deployment; it is **not** a place to store your static files > permanently. You should do that in directories that will be found by > [staticfiles](/ja/3.2/ref/contrib/staticfiles/)’s > [`finders`](#std-setting-STATICFILES_FINDERS), which by default, are > `'static/'` app sub-directories and any directories you include in > [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS)). ### `STATIC_URL` デフォルト値: `None` URL to use when referring to static files located in [`STATIC_ROOT`](#std-setting-STATIC_ROOT). Example: `"/static/"` or `"http://static.example.com/"` If not `None`, this will be used as the base path for [asset definitions](/ja/3.2/topics/forms/media/#form-asset-paths) (the `Media` class) and the [staticfiles app](/ja/3.2/ref/contrib/staticfiles/). It must end in a slash if set to a non-empty value. You may need to [configure these files to be served in development](/ja/3.2/howto/static-files/#serving-static-files-in-development) and will definitely need to do so [in production](/ja/3.2/howto/static-files/deployment/). > **Note** > > If [`STATIC_URL`](#std-setting-STATIC_URL) is a relative path, then it will be prefixed by > the server-provided value of `SCRIPT_NAME` (or `/` if not set). This > makes it easier to serve a Django application in a subpath without adding > an extra configuration to the settings. ### `STATICFILES_DIRS` デフォルト値: `[]` (空のリスト) この設定は `FileSystemFinder` のファインダーが有効になっている場合に staticfiles アプリが通過する追加の場所を定義します。例えば、 [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) や [`findstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-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" \`\` ）。 #### プレフィックス(オプション) In case you want to refer to files in one of the locations with an additional namespace, you can **optionally** provide a prefix as `(prefix, path)` tuples, e.g.: ``` STATICFILES_DIRS = [ # ... ("downloads", "/opt/webfiles/stats"), ] ``` For example, assuming you have [`STATIC_URL`](#std-setting-STATIC_URL) set to `'/static/'`, the [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command would collect the "stats" files in a `'downloads'` subdirectory of [`STATIC_ROOT`](#std-setting-STATIC_ROOT). This would allow you to refer to the local file `'/opt/webfiles/stats/polls_20101022.tar.gz'` with `'/static/downloads/polls_20101022.tar.gz'` in your templates, e.g.: ```html+django ``` ### `STATICFILES_STORAGE` デフォルト値: `'django.contrib.staticfiles.storage.StaticFilesStorage'` The file storage engine to use when collecting static files with the [`collectstatic`](/ja/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command. A ready-to-use instance of the storage backend defined in this setting can be found at `django.contrib.staticfiles.storage.staticfiles_storage`. For an example, see [クラウドサービスや CDN から静的ファイルを配信する](/ja/3.2/howto/static-files/deployment/#staticfiles-from-cdn). ### `STATICFILES_FINDERS` デフォルト値: ``` [ 'django.contrib.staticfiles.finders.FileSystemFinder', 'django.contrib.staticfiles.finders.AppDirectoriesFinder', ] ``` The list of finder backends that know how to find static files in various locations. The default will find files stored in the [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS) setting (using `django.contrib.staticfiles.finders.FileSystemFinder`) and in a `static` subdirectory of each app (using `django.contrib.staticfiles.finders.AppDirectoriesFinder`). If multiple files with the same name are present, the first file that is found will be used. One finder is disabled by default: `django.contrib.staticfiles.finders.DefaultStorageFinder`. If added to your [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS) setting, it will look for static files in the default file storage as defined by the [`DEFAULT_FILE_STORAGE`](#std-setting-DEFAULT_FILE_STORAGE) setting. > **Note** > > When using the `AppDirectoriesFinder` finder, make sure your apps > can be found by staticfiles by adding the app to the > [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) setting of your site. Static file finders are currently considered a private interface, and this interface is thus undocumented. ## Core Settings Topical Index ### キャッシュ - [`CACHES`](#std-setting-CACHES) - [`CACHE_MIDDLEWARE_ALIAS`](#std-setting-CACHE_MIDDLEWARE_ALIAS) - [`CACHE_MIDDLEWARE_KEY_PREFIX`](#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX) - [`CACHE_MIDDLEWARE_SECONDS`](#std-setting-CACHE_MIDDLEWARE_SECONDS) ### データベース - [`DATABASES`](#std-setting-DATABASES) - [`DATABASE_ROUTERS`](#std-setting-DATABASE_ROUTERS) - [`DEFAULT_INDEX_TABLESPACE`](#std-setting-DEFAULT_INDEX_TABLESPACE) - [`DEFAULT_TABLESPACE`](#std-setting-DEFAULT_TABLESPACE) ### Debugging - [`DEBUG`](#std-setting-DEBUG) - [`DEBUG_PROPAGATE_EXCEPTIONS`](#std-setting-DEBUG_PROPAGATE_EXCEPTIONS) ### メールアドレス - [`ADMINS`](#std-setting-ADMINS) - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL) - [`EMAIL_BACKEND`](#std-setting-EMAIL_BACKEND) - [`EMAIL_FILE_PATH`](#std-setting-EMAIL_FILE_PATH) - [`EMAIL_HOST`](#std-setting-EMAIL_HOST) - [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD) - [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) - [`EMAIL_PORT`](#std-setting-EMAIL_PORT) - [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) - [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) - [`EMAIL_SUBJECT_PREFIX`](#std-setting-EMAIL_SUBJECT_PREFIX) - [`EMAIL_TIMEOUT`](#std-setting-EMAIL_TIMEOUT) - [`EMAIL_USE_LOCALTIME`](#std-setting-EMAIL_USE_LOCALTIME) - [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) - [`MANAGERS`](#std-setting-MANAGERS) - [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL) ### エラーのレポート - [`DEFAULT_EXCEPTION_REPORTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER) - [`DEFAULT_EXCEPTION_REPORTER_FILTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER) - [`IGNORABLE_404_URLS`](#std-setting-IGNORABLE_404_URLS) - [`MANAGERS`](#std-setting-MANAGERS) - [`SILENCED_SYSTEM_CHECKS`](#std-setting-SILENCED_SYSTEM_CHECKS) ### File uploads - [`DEFAULT_FILE_STORAGE`](#std-setting-DEFAULT_FILE_STORAGE) - [`FILE_UPLOAD_HANDLERS`](#std-setting-FILE_UPLOAD_HANDLERS) - [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) - [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS) - [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR) - [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) - [`MEDIA_URL`](#std-setting-MEDIA_URL) ### フォーム - [`FORM_RENDERER`](#std-setting-FORM_RENDERER) ### Globalization (`i18n`/`l10n`) - [`DATE_FORMAT`](#std-setting-DATE_FORMAT) - [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) - [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT) - [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) - [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) - [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK) - [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH) - [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE) - [`LANGUAGE_COOKIE_AGE`](#std-setting-LANGUAGE_COOKIE_AGE) - [`LANGUAGE_COOKIE_DOMAIN`](#std-setting-LANGUAGE_COOKIE_DOMAIN) - [`LANGUAGE_COOKIE_HTTPONLY`](#std-setting-LANGUAGE_COOKIE_HTTPONLY) - [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) - [`LANGUAGE_COOKIE_PATH`](#std-setting-LANGUAGE_COOKIE_PATH) - [`LANGUAGE_COOKIE_SAMESITE`](#std-setting-LANGUAGE_COOKIE_SAMESITE) - [`LANGUAGE_COOKIE_SECURE`](#std-setting-LANGUAGE_COOKIE_SECURE) - [`LANGUAGES`](#std-setting-LANGUAGES) - [`LANGUAGES_BIDI`](#std-setting-LANGUAGES_BIDI) - [`LOCALE_PATHS`](#std-setting-LOCALE_PATHS) - [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT) - [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) - [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) - [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) - [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) - [`TIME_FORMAT`](#std-setting-TIME_FORMAT) - [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) - [`TIME_ZONE`](#std-setting-TIME_ZONE) - [`USE_I18N`](#std-setting-USE_I18N) - [`USE_L10N`](#std-setting-USE_L10N) - [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) - [`USE_TZ`](#std-setting-USE_TZ) - [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) ### HTTP - [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE) - [`DATA_UPLOAD_MAX_NUMBER_FIELDS`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FIELDS) - [`DATA_UPLOAD_MAX_NUMBER_FILES`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FILES) - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`DISALLOWED_USER_AGENTS`](#std-setting-DISALLOWED_USER_AGENTS) - [`FORCE_SCRIPT_NAME`](#std-setting-FORCE_SCRIPT_NAME) - [`INTERNAL_IPS`](#std-setting-INTERNAL_IPS) - [`MIDDLEWARE`](#std-setting-MIDDLEWARE) - セキュリティ - [`SECURE_BROWSER_XSS_FILTER`](#std-setting-SECURE_BROWSER_XSS_FILTER) - [`SECURE_CONTENT_TYPE_NOSNIFF`](#std-setting-SECURE_CONTENT_TYPE_NOSNIFF) - [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) - [`SECURE_HSTS_PRELOAD`](#std-setting-SECURE_HSTS_PRELOAD) - [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) - [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER) - [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT) - [`SECURE_REFERRER_POLICY`](#std-setting-SECURE_REFERRER_POLICY) - [`SECURE_SSL_HOST`](#std-setting-SECURE_SSL_HOST) - [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) - [`SIGNING_BACKEND`](#std-setting-SIGNING_BACKEND) - [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) - [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT) - [`WSGI_APPLICATION`](#std-setting-WSGI_APPLICATION) ### ロギング - [`LOGGING`](#std-setting-LOGGING) - [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) ### モデル - [`ABSOLUTE_URL_OVERRIDES`](#std-setting-ABSOLUTE_URL_OVERRIDES) - [`FIXTURE_DIRS`](#std-setting-FIXTURE_DIRS) - [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) ### セキュリティ - Cross Site Request Forgery Protection - [`CSRF_COOKIE_DOMAIN`](#std-setting-CSRF_COOKIE_DOMAIN) - [`CSRF_COOKIE_NAME`](#std-setting-CSRF_COOKIE_NAME) - [`CSRF_COOKIE_PATH`](#std-setting-CSRF_COOKIE_PATH) - [`CSRF_COOKIE_SAMESITE`](#std-setting-CSRF_COOKIE_SAMESITE) - [`CSRF_COOKIE_SECURE`](#std-setting-CSRF_COOKIE_SECURE) - [`CSRF_FAILURE_VIEW`](#std-setting-CSRF_FAILURE_VIEW) - [`CSRF_HEADER_NAME`](#std-setting-CSRF_HEADER_NAME) - [`CSRF_TRUSTED_ORIGINS`](#std-setting-CSRF_TRUSTED_ORIGINS) - [`CSRF_USE_SESSIONS`](#std-setting-CSRF_USE_SESSIONS) - [`SECRET_KEY`](#std-setting-SECRET_KEY) - [`X_FRAME_OPTIONS`](#std-setting-X_FRAME_OPTIONS) ### シリアル化 - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`SERIALIZATION_MODULES`](#std-setting-SERIALIZATION_MODULES) ### テンプレート - [`TEMPLATES`](#std-setting-TEMPLATES) ### テスト - Database: [`TEST`](#std-setting-DATABASE-TEST) - [`TEST_NON_SERIALIZED_APPS`](#std-setting-TEST_NON_SERIALIZED_APPS) - [`TEST_RUNNER`](#std-setting-TEST_RUNNER) ### URL - [`APPEND_SLASH`](#std-setting-APPEND_SLASH) - [`PREPEND_WWW`](#std-setting-PREPEND_WWW) - [`ROOT_URLCONF`](#std-setting-ROOT_URLCONF)