Sophie: python-django-doc-1.8.19-1.mga6 noarch

python-django-doc-1.8.19-1.mga6.noarch.rpm

========
Settings
========

.. contents::
:local:
:depth: 1

.. warning::

Be careful when you override settings, especially when the default value
is a non-empty tuple or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
and :setting:`STATICFILES_FINDERS`. Make sure you keep the components
required by the features of Django you wish to use.

Core Settings
=============

Here's a list of settings available in Django core and their default values.
Settings provided by contrib apps are listed below, followed by a topical index
of the core settings. For introductory material, see the :doc:`settings topic
guide </topics/settings>`.

.. setting:: ABSOLUTE_URL_OVERRIDES

ABSOLUTE_URL_OVERRIDES
----------------------

Default: ``{}`` (Empty dictionary)

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),
}

Note that the model name used in this setting should be all lower-case, regardless
of the case of the actual model class name.

.. versionchanged:: 1.7.1

``ABSOLUTE_URL_OVERRIDES`` now works on models that don't declare
``get_absolute_url()``.

.. setting:: ADMINS

ADMINS
------

Default: ``()`` (Empty tuple)

A tuple that lists people who get code error notifications. When
``DEBUG=False`` and a view raises an exception, Django will email these people
with the full exception information. Each member of the tuple should be a tuple
of (Full name, email address). Example::

(('John', 'john@example.com'), ('Mary', 'mary@example.com'))

Note that Django will email *all* of these people whenever an error happens.
See :doc:`/howto/error-reporting` for more information.

.. setting:: ALLOWED_HOSTS

ALLOWED_HOSTS
-------------

Default: ``[]`` (Empty list)

A list of strings representing the host/domain names that this Django site can
serve. This is a security measure to prevent an attacker from poisoning caches
and triggering password reset emails with links to malicious hosts by submitting
requests with a fake HTTP ``Host`` header, which is possible even under many
seemingly-safe web server configurations.

Values in this list can be fully qualified names (e.g. ``'www.example.com'``),
in which case they will be matched against the request's ``Host`` header
exactly (case-insensitive, not including port). A value beginning with a period
can be used as a subdomain wildcard: ``'.example.com'`` will match
``example.com``, ``www.example.com``, and any other subdomain of
``example.com``. A value of ``'*'`` will match anything; in this case you are
responsible to provide your own validation of the ``Host`` header (perhaps in a
middleware; if so this middleware must be listed first in
:setting:`MIDDLEWARE_CLASSES`).

.. versionchanged:: 1.7

In previous versions of Django, if you wanted to also allow the
`fully qualified domain name (FQDN)`_, which some browsers can send in the
``Host`` header, you had to explicitly add another ``ALLOWED_HOSTS`` entry
that included a trailing period. This entry could also be a subdomain
wildcard::

ALLOWED_HOSTS = [
'.example.com', # Allow domain and subdomains
'.example.com.', # Also allow FQDN and subdomains
]

In Django 1.7, the trailing dot is stripped when performing host validation,
thus an entry with a trailing dot isn't required.

.. _`fully qualified domain name (FQDN)`: https://en.wikipedia.org/wiki/Fully_qualified_domain_name

If the ``Host`` header (or ``X-Forwarded-Host`` if
:setting:`USE_X_FORWARDED_HOST` is enabled) does not match any value in this
list, the :meth:`django.http.HttpRequest.get_host()` method will raise
:exc:`~django.core.exceptions.SuspiciousOperation`.

When :setting:`DEBUG` is ``True`` and ``ALLOWED_HOSTS`` is empty, the host
is validated against ``['localhost', '127.0.0.1', '[::1]']``.

This validation only applies via :meth:`~django.http.HttpRequest.get_host()`;
if your code accesses the ``Host`` header directly from ``request.META`` you
are bypassing this security protection.

.. versionchanged:: 1.8.16

In older versions, ``ALLOWED_HOSTS`` wasn't checked if ``DEBUG=True``, but
it's now checked to prevent a DNS rebinding attack.

.. setting:: ALLOWED_INCLUDE_ROOTS

ALLOWED_INCLUDE_ROOTS
---------------------

Default: ``()`` (Empty tuple)

.. deprecated:: 1.8

This setting, along with the :ttag:`ssi` template tag, is deprecated and
will be removed in Django 1.10.

.. versionchanged:: 1.8

You can also set the ``'allowed_include_roots'`` option in the
:setting:`OPTIONS <TEMPLATES-OPTIONS>` of a ``DjangoTemplates`` backend
instead.

A tuple of strings representing allowed prefixes for the ``{% ssi %}`` template
tag. This is a security measure, so that template authors can't access files
that they shouldn't be accessing.

For example, if :setting:`ALLOWED_INCLUDE_ROOTS` is ``('/home/html', '/var/www')``,
then ``{% ssi /home/html/foo.txt %}`` would work, but ``{% ssi /etc/passwd %}``
wouldn't.

.. setting:: APPEND_SLASH

APPEND_SLASH
------------

Default: ``True``

When set to ``True``, if the request URL does not match any of the patterns
in the URLconf and it doesn't end in a slash, an HTTP redirect is issued to the
same URL with a slash appended. Note that the redirect may cause any data
submitted in a POST request to be lost.

The :setting:`APPEND_SLASH` setting is only used if
:class:`~django.middleware.common.CommonMiddleware` is installed
(see :doc:`/topics/http/middleware`). See also :setting:`PREPEND_WWW`.

.. setting:: CACHES

CACHES
------

Default::

{
'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 :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.

.. setting:: CACHES-BACKEND

BACKEND
~~~~~~~

Default: ``''`` (Empty string)

The cache backend to use. The built-in cache backends are:

* ``'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.MemcachedCache'``
* ``'django.core.cache.backends.memcached.PyLibMCCache'``

You can use a cache backend that doesn't ship with Django by setting
:setting:`BACKEND <CACHES-BACKEND>` to a fully-qualified path of a cache
backend class (i.e. ``mypackage.backends.whatever.WhateverCache``).

.. setting:: CACHES-KEY_FUNCTION

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 :ref:`cache documentation <cache_key_transformation>` for more
information.

.. setting:: CACHES-KEY_PREFIX

KEY_PREFIX
~~~~~~~~~~

Default: ``''`` (Empty string)

A string that will be automatically included (prepended by default) to
all cache keys used by the Django server.

See the :ref:`cache documentation <cache_key_prefixing>` for more information.

.. setting:: CACHES-LOCATION

LOCATION
~~~~~~~~

Default: ``''`` (Empty string)

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 simply an
identifying name for a local memory cache. e.g.::

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

.. setting:: CACHES-OPTIONS

OPTIONS
~~~~~~~

Default: 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
:doc:`Cache Backends </topics/cache>` documentation. For more information,
consult your backend module's own documentation.

.. setting:: CACHES-TIMEOUT

TIMEOUT
~~~~~~~

Default: 300

The number of seconds before a cache entry is considered stale.

.. versionadded:: 1.7

If the value of this settings is ``None``, cache entries will not expire.

.. setting:: CACHES-VERSION

VERSION
~~~~~~~

Default: ``1``

The default version number for cache keys generated by the Django server.

See the :ref:`cache documentation <cache_versioning>` for more information.

.. setting:: CACHE_MIDDLEWARE_ALIAS

CACHE_MIDDLEWARE_ALIAS
----------------------

Default: ``default``

The cache connection to use for the :ref:`cache middleware
<the-per-site-cache>`.

.. setting:: CACHE_MIDDLEWARE_KEY_PREFIX

CACHE_MIDDLEWARE_KEY_PREFIX
---------------------------

Default: ``''`` (Empty string)

A string which will be prefixed to the cache keys generated by the :ref:`cache
middleware <the-per-site-cache>`. This prefix is combined with the
:setting:`KEY_PREFIX <CACHES-KEY_PREFIX>` setting; it does not replace it.

See :doc:`/topics/cache`.

.. setting:: CACHE_MIDDLEWARE_SECONDS

CACHE_MIDDLEWARE_SECONDS
------------------------

Default: ``600``

The default number of seconds to cache a page for the :ref:`cache middleware
<the-per-site-cache>`.

See :doc:`/topics/cache`.

.. _settings-csrf:

.. setting:: CSRF_COOKIE_AGE

CSRF_COOKIE_AGE
---------------

.. versionadded:: 1.7

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.

.. setting:: CSRF_COOKIE_DOMAIN

CSRF_COOKIE_DOMAIN
------------------

Default: ``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
:ref:`CSRF limitations <csrf-limitations>` section.

.. setting:: CSRF_COOKIE_HTTPONLY

CSRF_COOKIE_HTTPONLY
--------------------

Default: ``False``

Whether to use ``HttpOnly`` flag on the CSRF cookie. If this is set to
``True``, client-side JavaScript will not to be able to access the CSRF cookie.

This can help prevent malicious JavaScript from bypassing CSRF protection. If
you enable this and need to send the value of the CSRF token with Ajax requests,
your JavaScript will need to pull the value from a hidden CSRF token form input
on the page instead of from the cookie.

See :setting:`SESSION_COOKIE_HTTPONLY` for details on ``HttpOnly``.

.. setting:: CSRF_COOKIE_NAME

CSRF_COOKIE_NAME
----------------

Default: ``'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 :doc:`/ref/csrf`.

.. setting:: CSRF_COOKIE_PATH

CSRF_COOKIE_PATH
----------------

Default: ``'/'``

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.

.. setting:: CSRF_COOKIE_SECURE

CSRF_COOKIE_SECURE
------------------

Default: ``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.

.. setting:: CSRF_FAILURE_VIEW

CSRF_FAILURE_VIEW
-----------------

Default: ``'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. 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. See
:doc:`/ref/csrf`.

.. setting:: DATABASES

DATABASES
---------

Default: ``{}`` (Empty dictionary)

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 :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 MySQL, Oracle, or
PostgreSQL, additional connection parameters will be required. See
the :setting:`ENGINE <DATABASE-ENGINE>` setting below on how to specify
other database types. This example is for PostgreSQL::

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'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:

.. setting:: DATABASE-ATOMIC_REQUESTS

ATOMIC_REQUESTS
~~~~~~~~~~~~~~~

Default: ``False``

Set this to ``True`` to wrap each view in a transaction on this database. See
:ref:`tying-transactions-to-http-requests`.

.. setting:: DATABASE-AUTOCOMMIT

AUTOCOMMIT
~~~~~~~~~~

Default: ``True``

Set this to ``False`` if you want to :ref:`disable Django's transaction
management <deactivate-transaction-management>` and implement your own.

.. setting:: DATABASE-ENGINE

ENGINE
~~~~~~

Default: ``''`` (Empty string)

The database backend to use. The built-in database backends are:

* ``'django.db.backends.postgresql_psycopg2'``
* ``'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``).

.. setting:: HOST

HOST
~~~~

Default: ``''`` (Empty string)

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 :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 :setting:`HOST` to 'localhost'
or '127.0.0.1' ('host' lines in ``pg_hba.conf``).
On Windows, you should always define :setting:`HOST`, as UNIX domain sockets
are not available.

.. setting:: NAME

NAME
~~~~

Default: ``''`` (Empty string)

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``).

.. setting:: CONN_MAX_AGE

CONN_MAX_AGE
~~~~~~~~~~~~

Default: ``0``

The lifetime of a database connection, in seconds. Use ``0`` to close database
connections at the end of each request â Django's historical behavior â and
``None`` for unlimited persistent connections.

.. setting:: OPTIONS

OPTIONS
~~~~~~~

Default: ``{}`` (Empty dictionary)

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
:doc:`Database Backends </ref/databases>` documentation. For more information,
consult your backend module's own documentation.

.. setting:: PASSWORD

PASSWORD
~~~~~~~~

Default: ``''`` (Empty string)

The password to use when connecting to the database. Not used with SQLite.

.. setting:: PORT

PORT
~~~~

Default: ``''`` (Empty string)

The port to use when connecting to the database. An empty string means the
default port. Not used with SQLite.

.. setting:: USER

USER
~~~~

Default: ``''`` (Empty string)

The username to use when connecting to the database. Not used with SQLite.

.. setting:: DATABASE-TEST

TEST
~~~~

.. versionchanged:: 1.7

All :setting:`TEST <DATABASE-TEST>` sub-entries used to be independent
entries in the database settings dictionary, with a ``TEST_`` prefix.
For backwards compatibility with older versions of Django, you can define
both versions of the settings as long as they match.
Further, ``TEST_CREATE``, ``TEST_USER_CREATE`` and ``TEST_PASSWD``
were changed to ``CREATE_DB``, ``CREATE_USER`` and ``PASSWORD``
respectively.

Default: ``{}``

A dictionary of settings for test databases; for more details about the
creation and use of test databases, see :ref:`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:

.. setting:: TEST_CHARSET

CHARSET
^^^^^^^

Default: ``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 for the PostgreSQL_ (``postgresql_psycopg2``) and MySQL_ (``mysql``)
backends.

.. _PostgreSQL: http://www.postgresql.org/docs/current/static/multibyte.html
.. _MySQL: http://dev.mysql.com/doc/refman/5.6/en/charset-database.html

.. setting:: TEST_COLLATION

COLLATION
^^^^^^^^^

Default: ``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`_ for details).

.. _MySQL manual: MySQL_

.. setting:: TEST_DEPENDENCIES

DEPENDENCIES
^^^^^^^^^^^^

Default: ``['default']``, for all databases other than ``default``,
which has no dependencies.

The creation-order dependencies of the database. See the documentation
on :ref:`controlling the creation order of test databases
<topics-testing-creation-dependencies>` for details.

.. setting:: TEST_MIRROR

MIRROR
^^^^^^

Default: ``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
:ref:`testing primary/replica configurations
<topics-testing-primaryreplica>` for details.

.. setting:: TEST_NAME

NAME
^^^^

Default: ``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 :ref:`the-test-database`.

.. setting:: TEST_SERIALIZE

SERIALIZE
^^^^^^^^^

.. versionadded:: 1.7.1

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 :ref:`serialized_rollback=True <test-case-serialized-rollback>`.

.. setting:: TEST_CREATE

CREATE_DB
^^^^^^^^^

Default: ``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.

.. setting:: TEST_USER_CREATE

CREATE_USER
^^^^^^^^^^^

Default: ``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.

.. setting:: TEST_USER

USER
^^^^

Default: ``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``.

.. setting:: TEST_PASSWD

PASSWORD
^^^^^^^^

Default: ``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.

.. versionchanged:: 1.8.16

Older versions used a hardcoded default password.

.. setting:: TEST_TBLSPACE

TBLSPACE
^^^^^^^^

Default: ``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``.

.. versionchanged:: 1.8

Previously Django used ``'test_' + NAME`` if not provided.

.. setting:: TEST_TBLSPACE_TMP

TBLSPACE_TMP
^^^^^^^^^^^^

Default: ``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'``.

.. versionchanged:: 1.8

Previously Django used ``'test_' + NAME + '_temp'`` if not provided.

.. setting:: DATAFILE

DATAFILE
^^^^^^^^

.. versionadded:: 1.8

Default: ``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'``.

.. setting:: DATAFILE_TMP

DATAFILE_TMP
^^^^^^^^^^^^

.. versionadded:: 1.8

Default: ``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'``.

.. setting:: DATAFILE_MAXSIZE

DATAFILE_MAXSIZE
^^^^^^^^^^^^^^^^

.. versionadded:: 1.8

Default: ``'500M'``

.. versionchanged:: 1.8

The previous value was 200M and was not user customizable.

This is an Oracle-specific setting.

The maximum size that the DATAFILE is allowed to grow to.

.. setting:: DATAFILE_TMP_MAXSIZE

DATAFILE_TMP_MAXSIZE
^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 1.8

Default: ``'500M'``

.. versionchanged:: 1.8

The previous value was 200M and was not user customizable.

This is an Oracle-specific setting.

The maximum size that the DATAFILE_TMP is allowed to grow to.

.. setting:: OLD_TEST_CHARSET

TEST_CHARSET
~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`CHARSET <TEST_CHARSET>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_COLLATION

TEST_COLLATION
~~~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`COLLATION <TEST_COLLATION>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_DEPENDENCIES

TEST_DEPENDENCIES
~~~~~~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`DEPENDENCIES <TEST_DEPENDENCIES>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_MIRROR

TEST_MIRROR
~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`MIRROR <TEST_MIRROR>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_NAME

TEST_NAME
~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`NAME <TEST_NAME>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_CREATE

TEST_CREATE
~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`CREATE_DB <TEST_CREATE>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_USER

TEST_USER
~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`USER <TEST_USER>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_USER_CREATE

TEST_USER_CREATE
~~~~~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`CREATE_USER <TEST_USER_CREATE>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_PASSWD

TEST_PASSWD
~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`PASSWORD <TEST_PASSWD>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_TBLSPACE

TEST_TBLSPACE
~~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`TBLSPACE <TEST_TBLSPACE>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: OLD_TEST_TBLSPACE_TMP

TEST_TBLSPACE_TMP
~~~~~~~~~~~~~~~~~

.. deprecated:: 1.7

Use the :setting:`TBLSPACE_TMP <TEST_TBLSPACE_TMP>` entry in the
:setting:`TEST <DATABASE-TEST>` dictionary.

.. setting:: DATABASE_ROUTERS

DATABASE_ROUTERS
----------------

Default: ``[]`` (Empty list)

The list of routers that will be used to determine which database
to use when performing a database query.

See the documentation on :ref:`automatic database routing in multi
database configurations <topics-db-multi-db-routing>`.

.. setting:: DATE_FORMAT

DATE_FORMAT
-----------

Default: ``'N j, Y'`` (e.g. ``Feb. 4, 2003``)

The default formatting to use for displaying date fields in any part of the
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
locale-dictated format has higher precedence and will be applied instead. See
:tfilter:`allowed date format strings <date>`.

See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`.

.. setting:: DATE_INPUT_FORMATS

DATE_INPUT_FORMATS
------------------

Default::

(
'%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 tuple 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, not the format strings
from the ``date`` Django template tag.

When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
precedence and will be applied instead.

See also :setting:`DATETIME_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.

.. _datetime: https://docs.python.org/library/datetime.html#strftime-strptime-behavior

.. setting:: DATETIME_FORMAT

DATETIME_FORMAT
---------------

Default: ``'N j, Y, P'`` (e.g. ``Feb. 4, 2003, 4 p.m.``)

The default formatting to use for displaying datetime fields in any part of the
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
locale-dictated format has higher precedence and will be applied instead. See
:tfilter:`allowed date format strings <date>`.

See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.

.. setting:: DATETIME_INPUT_FORMATS

DATETIME_INPUT_FORMATS
----------------------

Default::

(
'%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'
'%Y-%m-%d', # '2006-10-25'
'%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', # '10/25/2006'
'%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'
'%m/%d/%y', # '10/25/06'
)

A tuple 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, not the format
strings from the ``date`` Django template tag.

When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
precedence and will be applied instead.

See also :setting:`DATE_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.

.. _datetime: https://docs.python.org/library/datetime.html#strftime-strptime-behavior

.. setting:: DEBUG

DEBUG
-----

Default: ``False``

A boolean that turns on/off debug mode.

Never deploy a site into production with :setting:`DEBUG` turned on.

Did you catch that? NEVER deploy a site into production with :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 :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 (or offensive), such as :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 :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 :setting:`DEBUG` is ``False``, you also need to properly set
the :setting:`ALLOWED_HOSTS` setting. Failing to do so will result in all
requests being returned as "Bad Request (400)".

.. note::

The default :file:`settings.py` file created by :djadmin:`django-admin
startproject <startproject>` sets ``DEBUG = True`` for convenience.

.. _django/views/debug.py: https://github.com/django/django/blob/master/django/views/debug.py

.. setting:: DEBUG_PROPAGATE_EXCEPTIONS

DEBUG_PROPAGATE_EXCEPTIONS
--------------------------

Default: ``False``

If set to True, Django's normal exception handling of view functions
will be suppressed, and exceptions will propagate upwards. This can
be useful for some test setups, and should never be used on a live
site.

.. setting:: DECIMAL_SEPARATOR

DECIMAL_SEPARATOR
-----------------

Default: ``'.'`` (Dot)

Default decimal separator used when formatting decimal numbers.

Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated
format has higher precedence and will be applied instead.

See also :setting:`NUMBER_GROUPING`, :setting:`THOUSAND_SEPARATOR` and
:setting:`USE_THOUSAND_SEPARATOR`.

.. setting:: DEFAULT_CHARSET

DEFAULT_CHARSET
---------------

Default: ``'utf-8'``

Default charset to use for all ``HttpResponse`` objects, if a MIME type isn't
manually specified. Used with :setting:`DEFAULT_CONTENT_TYPE` to construct the
``Content-Type`` header.

.. setting:: DEFAULT_CONTENT_TYPE

DEFAULT_CONTENT_TYPE
--------------------

Default: ``'text/html'``

Default content type to use for all ``HttpResponse`` objects, if a MIME type
isn't manually specified. Used with :setting:`DEFAULT_CHARSET` to construct
the ``Content-Type`` header.

.. setting:: DEFAULT_EXCEPTION_REPORTER_FILTER

DEFAULT_EXCEPTION_REPORTER_FILTER
---------------------------------

Default: :class:`django.views.debug.SafeExceptionReporterFilter`

Default exception reporter filter class to be used if none has been assigned to
the :class:`~django.http.HttpRequest` instance yet.
See :ref:`Filtering error reports<filtering-error-reports>`.

.. setting:: DEFAULT_FILE_STORAGE

DEFAULT_FILE_STORAGE
--------------------

Default: :class:`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 :doc:`/topics/files`.

.. setting:: DEFAULT_FROM_EMAIL

DEFAULT_FROM_EMAIL
------------------

Default: ``'webmaster@localhost'``

Default email address to use for various automated correspondence from the
site manager(s). This doesn't include error messages sent to :setting:`ADMINS`
and :setting:`MANAGERS`; for that, see :setting:`SERVER_EMAIL`.

.. setting:: DEFAULT_INDEX_TABLESPACE

DEFAULT_INDEX_TABLESPACE
------------------------

Default: ``''`` (Empty string)

Default tablespace to use for indexes on fields that don't specify
one, if the backend supports it (see :doc:`/topics/db/tablespaces`).

.. setting:: DEFAULT_TABLESPACE

DEFAULT_TABLESPACE
------------------

Default: ``''`` (Empty string)

Default tablespace to use for models that don't specify one, if the
backend supports it (see :doc:`/topics/db/tablespaces`).

.. setting:: DISALLOWED_USER_AGENTS

DISALLOWED_USER_AGENTS
----------------------

Default: ``()`` (Empty tuple)

List of compiled regular expression objects representing User-Agent strings that
are not allowed to visit any page, systemwide. Use this for bad robots/crawlers.
This is only used if ``CommonMiddleware`` is installed (see
:doc:`/topics/http/middleware`).

.. setting:: EMAIL_BACKEND

EMAIL_BACKEND
-------------

Default: ``'django.core.mail.backends.smtp.EmailBackend'``

The backend to use for sending emails. For the list of available backends see
:doc:`/topics/email`.

.. setting:: EMAIL_FILE_PATH

EMAIL_FILE_PATH
---------------

Default: Not defined

The directory used by the ``file`` email backend to store output files.

.. setting:: EMAIL_HOST

EMAIL_HOST
----------

Default: ``'localhost'``

The host to use for sending email.

See also :setting:`DEBUG`.

.. setting:: TEMPLATE_DIRS

TEMPLATE_DIRS
-------------

Default: ``()`` (Empty tuple)

.. deprecated:: 1.8

Set the :setting:`DIRS <TEMPLATES-DIRS>` option of a ``DjangoTemplates``
backend instead.

List of locations of the template source files searched by
:class:`django.template.loaders.filesystem.Loader`, in search order.

Note that these paths should use Unix-style forward slashes, even on Windows.

See :doc:`/ref/templates/language`.

.. setting:: TEMPLATE_LOADERS

TEMPLATE_LOADERS
----------------

Default::

('django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader')

.. deprecated:: 1.8

Set the ``'loaders'`` option in the :setting:`OPTIONS <TEMPLATES-OPTIONS>`
of a ``DjangoTemplates`` backend instead.

A tuple of template loader classes, specified as strings. Each ``Loader`` class
knows how to import templates from a particular source. Optionally, a tuple can be
used instead of a string. The first item in the tuple should be the ``Loader``âs
module, subsequent items are passed to the ``Loader`` during initialization. See
:doc:`/ref/templates/api`.

.. setting:: TEMPLATE_STRING_IF_INVALID

TEMPLATE_STRING_IF_INVALID
--------------------------

Default: ``''`` (Empty string)

.. deprecated:: 1.8

Set the ``'string_if_invalid'`` option in the :setting:`OPTIONS
<TEMPLATES-OPTIONS>` of a ``DjangoTemplates`` backend instead.

Output, as a string, that the template system should use for invalid (e.g.
misspelled) variables. See :ref:`invalid-template-variables`.

.. setting:: TEST_RUNNER

TEST_RUNNER
-----------

Default: ``'django.test.runner.DiscoverRunner'``

The name of the class to use for starting the test suite. See
:ref:`other-testing-frameworks`.

.. setting:: TEST_NON_SERIALIZED_APPS

TEST_NON_SERIALIZED_APPS
------------------------

.. versionadded:: 1.7

Default: ``[]`` (Empty list)

In order to restore the database state between tests for
``TransactionTestCase``\s and database backends without transactions, Django
will :ref:`serialize the contents of all apps <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.

.. setting:: THOUSAND_SEPARATOR

THOUSAND_SEPARATOR
------------------

Default: ``,`` (Comma)

Default thousand separator used when formatting numbers. This setting is
used only when :setting:`USE_THOUSAND_SEPARATOR` is ``True`` and
:setting:`NUMBER_GROUPING` is greater than ``0``.

Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated
format has higher precedence and will be applied instead.

See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and
:setting:`USE_THOUSAND_SEPARATOR`.

.. setting:: TIME_FORMAT

TIME_FORMAT
-----------

Default: ``'P'`` (e.g. ``4 p.m.``)

The default formatting to use for displaying time fields in any part of the
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
locale-dictated format has higher precedence and will be applied instead. See
:tfilter:`allowed date format strings <date>`.

See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.

.. setting:: TIME_INPUT_FORMATS

TIME_INPUT_FORMATS
------------------

Default::

(
'%H:%M:%S', # '14:30:59'
'%H:%M:%S.%f', # '14:30:59.000200'
'%H:%M', # '14:30'
)

A tuple 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, not the format strings
from the ``date`` Django template tag.

When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
precedence and will be applied instead.

See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.

.. _datetime: https://docs.python.org/library/datetime.html#strftime-strptime-behavior

.. setting:: TIME_ZONE

TIME_ZONE
---------

Default: ``'America/Chicago'``

A string representing the time zone for this installation, or ``None``. See
the `list of time zones`_.

.. note::
Since Django was first released with the :setting:`TIME_ZONE` set to
``'America/Chicago'``, the global setting (used if nothing is defined in
your project's ``settings.py``) remains ``'America/Chicago'`` for backwards
compatibility. New project templates default to ``'UTC'``.

Note that this isn't necessarily the time zone of the server. For example, one
server may serve multiple Django-powered sites, each with a separate time zone
setting.

When :setting:`USE_TZ` is ``False``, this is the time zone in which Django
will store all datetimes. When :setting:`USE_TZ` is ``True``, this is the
default time zone that Django will use to display datetimes in templates and
to interpret datetimes entered in forms.

Django sets the ``os.environ['TZ']`` variable to the time zone you specify in
the :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 under the following conditions:

* If you're using the manual configuration option as described in
:ref:`manually configuring settings
<settings-without-django-settings-module>`, or

* If you specify ``TIME_ZONE = None``. This will cause Django to fall back to
using the system timezone. However, this is discouraged when :setting:`USE_TZ
= True <USE_TZ>`, because it makes conversions between local time and UTC
less reliable.

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 cannot reliably use alternate time zones in a Windows environment.
If you're running Django on Windows, :setting:`TIME_ZONE` must be set to
match the system time zone.

.. _list of time zones: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

.. _pytz: http://pytz.sourceforge.net/

.. setting:: USE_ETAGS

USE_ETAGS
---------

Default: ``False``

A boolean that specifies whether to output the "Etag" header. This saves
bandwidth but slows down performance. This is used by the ``CommonMiddleware``
(see :doc:`/topics/http/middleware`) and in the``Cache Framework``
(see :doc:`/topics/cache`).

.. setting:: USE_I18N

USE_I18N
--------

Default: ``True``

A boolean that specifies whether Django's translation system should be enabled.
This provides an easy 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 :setting:`LANGUAGE_CODE`, :setting:`USE_L10N` and :setting:`USE_TZ`.

.. note::

The default :file:`settings.py` file created by :djadmin:`django-admin
startproject <startproject>` includes ``USE_I18N = True`` for convenience.

.. setting:: USE_L10N

USE_L10N
--------

Default: ``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 :setting:`LANGUAGE_CODE`, :setting:`USE_I18N` and :setting:`USE_TZ`.

.. note::

The default :file:`settings.py` file created by :djadmin:`django-admin
startproject <startproject>` includes ``USE_L10N = True`` for convenience.

.. setting:: USE_THOUSAND_SEPARATOR

USE_THOUSAND_SEPARATOR
----------------------

Default: ``False``

A boolean that specifies whether to display numbers using a thousand separator.
When :setting:`USE_L10N` is set to ``True`` and if this is also set to
``True``, Django will use the values of :setting:`THOUSAND_SEPARATOR` and
:setting:`NUMBER_GROUPING` to format numbers.

See also :setting:`DECIMAL_SEPARATOR`, :setting:`NUMBER_GROUPING` and
:setting:`THOUSAND_SEPARATOR`.

.. setting:: USE_TZ

USE_TZ
------

Default: ``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.
Otherwise, Django will use naive datetimes in local time.

See also :setting:`TIME_ZONE`, :setting:`USE_I18N` and :setting:`USE_L10N`.

.. note::

The default :file:`settings.py` file created by
:djadmin:`django-admin startproject <startproject>` includes
``USE_TZ = True`` for convenience.

.. setting:: USE_X_FORWARDED_HOST

USE_X_FORWARDED_HOST
--------------------

Default: ``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.

.. setting:: WSGI_APPLICATION

WSGI_APPLICATION
----------------

Default: ``None``

The full Python path of the WSGI application object that Django's built-in
servers (e.g. :djadmin:`runserver`) will use. The :djadmin:`django-admin
startproject <startproject>` management command will create a simple
``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 :djadmin:`runserver` will be
identical to previous Django versions.

.. setting:: YEAR_MONTH_FORMAT

YEAR_MONTH_FORMAT
-----------------

Default: ``'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."

Note that if :setting:`USE_L10N` is set to ``True``, then the corresponding
locale-dictated format has higher precedence and will be applied.

See :tfilter:`allowed date format strings <date>`. See also
:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT`
and :setting:`MONTH_DAY_FORMAT`.

.. setting:: X_FRAME_OPTIONS

X_FRAME_OPTIONS
---------------

Default: ``'SAMEORIGIN'``

The default value for the X-Frame-Options header used by
:class:`~django.middleware.clickjacking.XFrameOptionsMiddleware`. See the
:doc:`clickjacking protection </ref/clickjacking/>` documentation.

Auth
====

Settings for :mod:`django.contrib.auth`.

.. setting:: AUTHENTICATION_BACKENDS

AUTHENTICATION_BACKENDS
-----------------------

Default: ``('django.contrib.auth.backends.ModelBackend',)``

A tuple of authentication backend classes (as strings) to use when attempting to
authenticate a user. See the :ref:`authentication backends documentation
<authentication-backends>` for details.

.. setting:: AUTH_USER_MODEL

AUTH_USER_MODEL
---------------

Default: 'auth.User'

The model to use to represent a User. See :ref:`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 :ref:`auth-custom-user` for more details.

.. setting:: LOGIN_REDIRECT_URL

LOGIN_REDIRECT_URL
------------------

Default: ``'/accounts/profile/'``

The URL where requests are redirected after login when the
``contrib.auth.login`` view gets no ``next`` parameter.

This is used by the :func:`~django.contrib.auth.decorators.login_required`
decorator, for example.

This setting also accepts :ref:`named URL patterns <naming-url-patterns>` which
can be used to reduce configuration duplication since you don't have to define
the URL in two places (``settings`` and URLconf).

.. deprecated:: 1.8

The setting may also be a dotted Python path to a view function. Support
for this will be removed in Django 1.10.

.. setting:: LOGIN_URL

LOGIN_URL
---------

Default: ``'/accounts/login/'``

The URL where requests are redirected for login, especially when using the
:func:`~django.contrib.auth.decorators.login_required` decorator.

.. deprecated:: 1.8

The setting may also be a dotted Python path to a view function. Support
for this will be removed in Django 1.10.

.. setting:: PASSWORD_RESET_TIMEOUT_DAYS

PASSWORD_RESET_TIMEOUT_DAYS
---------------------------

Default: ``3``

The number of days a password reset link is valid for. Used by the
:mod:`django.contrib.auth` password reset mechanism.

.. setting:: PASSWORD_HASHERS

PASSWORD_HASHERS
----------------

See :ref:`auth_password_storage`.

Default::

('django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher')

.. _settings-messages:

Messages
========

Settings for :mod:`django.contrib.messages`.

.. setting:: MESSAGE_LEVEL

MESSAGE_LEVEL
-------------

Default: ``messages.INFO``

Sets the minimum message level that will be recorded by the messages
framework. See :ref:`message levels <message-level>` for more details.

.. admonition:: 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 :ref:`constants table
<message-level-constants>`.

.. setting:: MESSAGE_STORAGE

MESSAGE_STORAGE
---------------

Default: ``'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 :ref:`message storage backends <message-storage-backends>` for more details.

The backends that use cookies --
:class:`~django.contrib.messages.storage.cookie.CookieStorage` and
:class:`~django.contrib.messages.storage.fallback.FallbackStorage` --
use the value of :setting:`SESSION_COOKIE_DOMAIN`, :setting:`SESSION_COOKIE_SECURE`
and :setting:`SESSION_COOKIE_HTTPONLY` when setting their cookies.

.. setting:: MESSAGE_TAGS

MESSAGE_TAGS
------------

Default::

{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 :ref:`message-displaying` above for more details.

.. admonition:: 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 :ref:`constants table
<message-level-constants>`.

.. _settings-sessions:

Sessions
========

Settings for :mod:`django.contrib.sessions`.

.. setting:: SESSION_CACHE_ALIAS

SESSION_CACHE_ALIAS
-------------------

Default: ``default``

If you're using :ref:`cache-based session storage <cached-sessions-backend>`,
this selects the cache to use.

.. setting:: SESSION_COOKIE_AGE

SESSION_COOKIE_AGE
------------------

Default: ``1209600`` (2 weeks, in seconds)

The age of session cookies, in seconds.

.. setting:: SESSION_COOKIE_DOMAIN

SESSION_COOKIE_DOMAIN
---------------------

Default: ``None``

The domain to use for session cookies. Set this to a string such as
``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
``None`` for a standard domain cookie.

This setting also affects cookies set by :mod:`django.contrib.messages`.

.. setting:: SESSION_COOKIE_HTTPONLY

SESSION_COOKIE_HTTPONLY
-----------------------

Default: ``True``

Whether to use ``HTTPOnly`` flag on the session cookie. If this is set to
``True``, client-side JavaScript will not to be able to access the
session cookie.

HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
is not part of the :rfc:`2109` standard for cookies, and it isn't honored
consistently by all browsers. However, when it is honored, it can be a
useful way to mitigate the risk of client side script accessing the
protected cookie data.

Turning it on makes it less trivial for an attacker to escalate a cross-site
scripting vulnerability into full hijacking of a user's session. There's not
much excuse for leaving this off, either: if your code depends on reading
session cookies from JavaScript, you're probably doing it wrong.

.. versionadded:: 1.7

This setting also affects cookies set by :mod:`django.contrib.messages`.

.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly

.. setting:: SESSION_COOKIE_NAME

SESSION_COOKIE_NAME
-------------------

Default: ``'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).

.. setting:: SESSION_COOKIE_PATH

SESSION_COOKIE_PATH
-------------------

Default: ``'/'``

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.

.. setting:: SESSION_COOKIE_SECURE

SESSION_COOKIE_SECURE
---------------------

Default: ``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.

Since it's trivial for a packet sniffer (e.g. `Firesheep`_) to hijack a user's
session if the session cookie is sent unencrypted, there's really no good
excuse to leave this off. It will prevent you from using sessions on insecure
requests and that's a good thing.

.. _Firesheep: http://codebutler.com/firesheep

.. versionadded:: 1.7

This setting also affects cookies set by :mod:`django.contrib.messages`.

.. setting:: SESSION_ENGINE

SESSION_ENGINE
--------------

Default: ``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 :ref:`configuring-sessions` for more details.

.. setting:: SESSION_EXPIRE_AT_BROWSER_CLOSE

SESSION_EXPIRE_AT_BROWSER_CLOSE
-------------------------------

Default: ``False``

Whether to expire the session when the user closes their browser. See
:ref:`browser-length-vs-persistent-sessions`.

.. setting:: SESSION_FILE_PATH

SESSION_FILE_PATH
-----------------

Default: ``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.

.. setting:: SESSION_SAVE_EVERY_REQUEST

SESSION_SAVE_EVERY_REQUEST
--------------------------

Default: ``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.

.. setting:: SESSION_SERIALIZER

SESSION_SERIALIZER
------------------

Default: ``'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 :ref:`session_serialization` for details, including a warning regarding
possible remote code execution when using
:class:`~django.contrib.sessions.serializers.PickleSerializer`.

Sites
=====

Settings for :mod:`django.contrib.sites`.

.. setting:: SITE_ID

SITE_ID
-------

Default: Not defined

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-staticfiles:

Static Files
============

Settings for :mod:`django.contrib.staticfiles`.

.. setting:: STATIC_ROOT

STATIC_ROOT
-----------

Default: ``None``

The absolute path to the directory where :djadmin:`collectstatic` will collect
static files for deployment.

Example: ``"/var/www/example.com/static/"``

If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
(default) the :djadmin:`collectstatic` management command will collect static
files into this directory. See the howto on :doc:`managing static
files</howto/static-files/index>` 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
:doc:`staticfiles</ref/contrib/staticfiles>`âs
:setting:`finders<STATICFILES_FINDERS>`, which by default, are
``'static/'`` app sub-directories and any directories you include in
:setting:`STATICFILES_DIRS`).

.. setting:: STATIC_URL

STATIC_URL
----------

Default: ``None``

URL to use when referring to static files located in :setting:`STATIC_ROOT`.

Example: ``"/static/"`` or ``"http://static.example.com/"``

If not ``None``, this will be used as the base path for
:ref:`asset definitions<form-asset-paths>` (the ``Media`` class) and the
:doc:`staticfiles app</ref/contrib/staticfiles>`.

It must end in a slash if set to a non-empty value.

You may need to :ref:`configure these files to be served in development
<serving-static-files-in-development>` and will definitely need to do so
:doc:`in production </howto/static-files/deployment>`.

.. setting:: STATICFILES_DIRS

STATICFILES_DIRS
----------------

Default: ``[]``

This setting defines the additional locations the staticfiles app will traverse
if the ``FileSystemFinder`` finder is enabled, e.g. if you use the
:djadmin:`collectstatic` or :djadmin:`findstatic` management command or use the
static file serving view.

This should be set to a list or tuple of strings that contain full paths to
your additional files directory(ies) e.g.::

STATICFILES_DIRS = (
"/home/special.polls.com/polls/static",
"/home/polls.com/polls/static",
"/opt/webfiles/common",
)

Note that these paths should use Unix-style forward slashes, even on Windows
(e.g. ``"C:/Users/user/mysite/extra_static_content"``).

Prefixes (optional)
~~~~~~~~~~~~~~~~~~~

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 :setting:`STATIC_URL` set to ``'/static/'``, the
:djadmin:`collectstatic` management command would collect the "stats" files
in a ``'downloads'`` subdirectory of :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.:

.. code-block:: html+django

.. setting:: STATICFILES_STORAGE

STATICFILES_STORAGE
-------------------

Default: ``'django.contrib.staticfiles.storage.StaticFilesStorage'``

The file storage engine to use when collecting static files with the
:djadmin:`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 :ref:`staticfiles-from-cdn`.

.. setting:: STATICFILES_FINDERS

STATICFILES_FINDERS
-------------------

Default::

("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 :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 :setting:`STATICFILES_FINDERS` setting, it will look for static files in
the default file storage as defined by the :setting:`DEFAULT_FILE_STORAGE`
setting.

.. note::

When using the ``AppDirectoriesFinder`` finder, make sure your apps
can be found by staticfiles. Simply add the app to the
: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
===========================

Cache
-----
* :setting:`CACHES`
* :setting:`CACHE_MIDDLEWARE_ALIAS`
* :setting:`CACHE_MIDDLEWARE_KEY_PREFIX`
* :setting:`CACHE_MIDDLEWARE_SECONDS`

Database
--------
* :setting:`DATABASES`
* :setting:`DATABASE_ROUTERS`
* :setting:`DEFAULT_INDEX_TABLESPACE`
* :setting:`DEFAULT_TABLESPACE`

Debugging
---------
* :setting:`DEBUG`
* :setting:`DEBUG_PROPAGATE_EXCEPTIONS`

Email
-----
* :setting:`ADMINS`
* :setting:`DEFAULT_CHARSET`
* :setting:`DEFAULT_FROM_EMAIL`
* :setting:`EMAIL_BACKEND`
* :setting:`EMAIL_FILE_PATH`
* :setting:`EMAIL_HOST`
* :setting:`EMAIL_HOST_PASSWORD`
* :setting:`EMAIL_HOST_USER`
* :setting:`EMAIL_PORT`
* :setting:`EMAIL_SSL_CERTFILE`
* :setting:`EMAIL_SSL_KEYFILE`
* :setting:`EMAIL_SUBJECT_PREFIX`
* :setting:`EMAIL_TIMEOUT`
* :setting:`EMAIL_USE_TLS`
* :setting:`MANAGERS`
* :setting:`SERVER_EMAIL`

Error reporting
---------------
* :setting:`DEFAULT_EXCEPTION_REPORTER_FILTER`
* :setting:`IGNORABLE_404_URLS`
* :setting:`MANAGERS`
* :setting:`SILENCED_SYSTEM_CHECKS`

.. _file-upload-settings:

File uploads
------------
* :setting:`DEFAULT_FILE_STORAGE`
* :setting:`FILE_CHARSET`
* :setting:`FILE_UPLOAD_HANDLERS`
* :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
* :setting:`FILE_UPLOAD_PERMISSIONS`
* :setting:`FILE_UPLOAD_TEMP_DIR`
* :setting:`MEDIA_ROOT`
* :setting:`MEDIA_URL`

Globalization (i18n/l10n)
-------------------------
* :setting:`DATE_FORMAT`
* :setting:`DATE_INPUT_FORMATS`
* :setting:`DATETIME_FORMAT`
* :setting:`DATETIME_INPUT_FORMATS`
* :setting:`DECIMAL_SEPARATOR`
* :setting:`FIRST_DAY_OF_WEEK`
* :setting:`FORMAT_MODULE_PATH`
* :setting:`LANGUAGE_CODE`
* :setting:`LANGUAGE_COOKIE_AGE`
* :setting:`LANGUAGE_COOKIE_DOMAIN`
* :setting:`LANGUAGE_COOKIE_NAME`
* :setting:`LANGUAGE_COOKIE_PATH`
* :setting:`LANGUAGES`
* :setting:`LOCALE_PATHS`
* :setting:`MONTH_DAY_FORMAT`
* :setting:`NUMBER_GROUPING`
* :setting:`SHORT_DATE_FORMAT`
* :setting:`SHORT_DATETIME_FORMAT`
* :setting:`THOUSAND_SEPARATOR`
* :setting:`TIME_FORMAT`
* :setting:`TIME_INPUT_FORMATS`
* :setting:`TIME_ZONE`
* :setting:`USE_I18N`
* :setting:`USE_L10N`
* :setting:`USE_THOUSAND_SEPARATOR`
* :setting:`USE_TZ`
* :setting:`YEAR_MONTH_FORMAT`

HTTP
----
* :setting:`DEFAULT_CHARSET`
* :setting:`DEFAULT_CONTENT_TYPE`
* :setting:`DISALLOWED_USER_AGENTS`
* :setting:`FORCE_SCRIPT_NAME`
* :setting:`INTERNAL_IPS`
* :setting:`MIDDLEWARE_CLASSES`
* Security

* :setting:`SECURE_BROWSER_XSS_FILTER`
* :setting:`SECURE_CONTENT_TYPE_NOSNIFF`
* :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS`
* :setting:`SECURE_HSTS_SECONDS`
* :setting:`SECURE_PROXY_SSL_HEADER`
* :setting:`SECURE_REDIRECT_EXEMPT`
* :setting:`SECURE_SSL_HOST`
* :setting:`SECURE_SSL_REDIRECT`
* :setting:`SIGNING_BACKEND`
* :setting:`USE_ETAGS`
* :setting:`USE_X_FORWARDED_HOST`
* :setting:`WSGI_APPLICATION`

Logging
-------
* :setting:`LOGGING`
* :setting:`LOGGING_CONFIG`

Models
------
* :setting:`ABSOLUTE_URL_OVERRIDES`
* :setting:`FIXTURE_DIRS`
* :setting:`INSTALLED_APPS`

Security
--------
* Cross Site Request Forgery Protection

* :setting:`CSRF_COOKIE_DOMAIN`
* :setting:`CSRF_COOKIE_NAME`
* :setting:`CSRF_COOKIE_PATH`
* :setting:`CSRF_COOKIE_SECURE`
* :setting:`CSRF_FAILURE_VIEW`

* :setting:`SECRET_KEY`
* :setting:`X_FRAME_OPTIONS`

Serialization
-------------
* :setting:`DEFAULT_CHARSET`
* :setting:`SERIALIZATION_MODULES`

Templates
---------
* :setting:`ALLOWED_INCLUDE_ROOTS`
* :setting:`TEMPLATES`
* :setting:`TEMPLATE_CONTEXT_PROCESSORS`
* :setting:`TEMPLATE_DEBUG`
* :setting:`TEMPLATE_DIRS`
* :setting:`TEMPLATE_LOADERS`
* :setting:`TEMPLATE_STRING_IF_INVALID`

Testing
-------
* Database: :setting:`TEST <DATABASE-TEST>`
* :setting:`TEST_NON_SERIALIZED_APPS`
* :setting:`TEST_RUNNER`

URLs
----
* :setting:`APPEND_SLASH`
* :setting:`PREPEND_WWW`
* :setting:`ROOT_URLCONF`